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The  Central  Archive  for  Reusable  Defense  Software  (CARDS)  Program,  sponsored  by  the  U.S 
Air  F(»ce  (ESC/ENS),  Hanscom  AFB,  MA,  has  been  investigating  business  areas  that  impact 
software  reuse.  An  on-  going  fcrum,  made  up  of  DoD  lawyers  and  contracting  officers  familiar 
with  software  reuse,  has  been  established  by  the  CARDS  Program  to  examine  legal  issues  and 
concerns  related  to  software  reuse.  One  primary  finding  from  these  software  reuse  legal  forums 
is;  risk  can  be  managed  by  carefully  negotiating  and  drafting  agreements. 

This  document  provides  sample  agreements  and  associated  guidelines  for  implementation  by 
the  CARDS  Library  staff.  They  are  based  on  the  current  CARDS  Command  Center  Library’s 
business,  q>erational  and  qualification  processes  and  concepts,  as  well  as  recommended  policy 
changes  [1]  [2].  This  will  allow  the  CARDS  Library  staff  to  interact  with  its  customers  (supplio^ 
of  components,  users  of  the  reusable  components,  and  interoperating  libraries)  to  help  reduce 
operating  risk,  meet  its  operational  and  technical  goals,  and  meet  the  needs  of  its  customers. 
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1  INTRODUCTION 

There  are  various  legal  issues  that  must  be  addressed  to  properly  plan  fcM*  and  carry  out  a 
software  reuse  program.  Legal  issues  are  dependent  upon  the  software  reuse  role  taken  by 
an  organization,  such  as,  developing  reusable  components,  reusing  existing  components,  and 
acquiring  and  distributing  these  components  via  libraries  or  reposittxies. 

This  document  addresses  library-related  legal  issues  and  provides  sample  agreements  for  use  by 
the  Central  Archive  for  Reusable  Defense  Software  (CARDS)  library  staff.  The  purpose  of  these 
guidelines  and  model  agreements  is  to  provide  a  mechanism  to  the  CARDS  library  to  interact 
with  its  customers  (suppliers  of  components,  users  of  the  reusable  components,  and  interoperating 
libraries)  in  a  manner  which  will  help  reduce  its  operating  risk,  meet  its  operational  and  technical 
goals,  and  meet  the  needs  of  its  customers. 

These  agreements  and  related  information  for  implementing  reuse  address  suppliers  of  compo¬ 
nents  and  library  accotmt  holders.  Interaction  with  other  libraries  is  addressed  by  examining 
interoperability  considerations.  First,  general  legal  issues  are  defined  (Section  2),  then  general 
guidance  in  {q)plying  these  agreements  to  the  CARDS  Library  is  presented  (Section  3).  Finally, 
sample  agreements  are  presented  fa*  suppliers  and  subscribers  (Sections  4  and  S).  Interoper¬ 
ability  issues  are  discussed  in  Section  6.  In  addition,  each  of  these  sections  has  an  introductory 
discussion  on  how  pertinent  issues  can  impact  that  particular  agreement. 

The  sample  clauses  for  agreements  contained  k  this  document  are  written  in  the  context  of  the 
CARDS  library.  They  are  based  on  the  current  CARDS  Command  Center  Library’s  business, 
operational  and  qualification  processes  and  concepts,  as  well  as  recommended  policy  changes 
[1]  [2],  The  agreements  may  have  to  be  modified  for  each  class  of  CARDS  customers,  and  also 
are  not  intended  to  be  used  verbatim  in  non-CARDS  applications. 


Page  1 


STARS-VC-B014A)01AX) 


25  Maich  1994 


2  LEGAL  ISSUES 

Many  perceive  that  legal  issues  can  inhibit  the  practice  of  software  reuse.  Although  legal 
issues  can  impact  the  management  of  a  software  reuse  library,  risks  and  liability  can  be  reduced 
if  these  issues  are  treated  within  the  context  of  a  business  strategy,  operational  concepts  and 
qierational  policies  and  procedures  [3].  There  are  two  types  of  legal  issues  that  are  pertinent 
to  managing  a  software  reuse  library.  They  are;  the  library’s  responsibilities  with  respect 
to  another’s  intellectual  property  rights  and  possible  liability  resulting  from  qualifying  and 
distributing  reusable  components. 

2.1  Intellectual  Property 

Intellectual  property  is  an  intangible  output  of  rational  thought  processes  which  has  some 
intellectual  or  informational  value.  Intellectual  property  can  be  protected  by  patents,  copyright 
or  trade  secrets  [3].  Copyright  protection  applies  to  the  expression  of  an  idea  and  to  copying  and 
existing  work.  For  an  individual,  copyright  protection  remains  in  effect  ftx  the  author’s  life  plus 
fifty  years.  For  a  work  for  hire,  the  duration  of  a  copyright  is  75  years  from  publication  or  100 
years  from  creation  (whichever  is  earlier).  It  does  not  tq^ply  to  works  that  look  similar,  but  were 
created  independently  from  the  copyrighted  work.  Copyright  law  allows  software  to  be  copied 
for  backup  and  archival  purposes  [3].  Patents  protect  ideas  and  give  the  inventor  the  exclusive 
right  to  prevent  others  from  making,  using  or  selling  the  invention  for  seventeen  years  after  the 
patent  is  issued  [3].  Patent  protection  for  software  is  not  only  new,  but  very  controversial.  Laws 
regarding  patent  protection  for  software  are  changing  on  a  regular  basis,  due  to  precedences 
arising  from  the  outcomes  of  various  law  suits.  A  patent  or  intellectual  property  lawyer  should 
be  consulted  for  any  matter  relating  to  patents.  A  trade  secret  is  any  formula,  process,  design 
or  intellectual  property  interest  which  is  protected  by  secrecy  [3].  Thus,  it  is  only  protected  by 
trade  secret  law  if  it  is  kept  a  secret. 

Various  levels  of  usage  rights  can  be  negotiated  under  Government  contracts.  The  Government 
can  not  currently  retain  title  (i.e.,  copyright)  nor  "have  the  rights"  to  contractor  developed 
components.  No  matter  what  rights  are  negotiated,  the  contractor  retains  the  copyright,  and 
the  Government  has  usage  rights  only,  which  include  the  right  for  others  to  use  for  Government 
purposes.  This  is  comparable  to  buying  a  license  to  use  a  commercial  product.  Government 
usage  rights  for  software  are:  unlimited  or  restricted.  For  technical  data.  Government  usage 
rights  can  be  unlimited,  limited  or  Government  Puipose  License  Rights  (GPLR).  Under  the 
Federal  Acquisition  Regulation  (FAR),  software  documentation  is  treated  as  software  and  has 
software  rights,  either  limited  or  restricted.  This  FAR  treatment  is  fairly  straight  forward,  i.e.,  the 
documentation  is  treated  the  same  as  the  software.  On  the  other  hand,  under  the  Defense  Federal 
Acquisition  Regulation  Supplement  (DFARS),  software  documentation  is  treated  as  technical 
data  and  has  data  rights,  not  software  rights  coverage.  This  is  more  complicated  since  the 
software  could  have  different  usage  rights  than  the  documentation  and  thus  would  have  to  be 
treated  differently.  An  exception  to  this  is  for  commercial  software  documentation,  which  can  be 
treated  as  software.  Whatever  the  level  of  rights,  the  FAR  and  DFARS  require  the  software  or 
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technical  data  to  be  marked  in  a  certain  way  and  also  has  certain  use,  distribution  and  modification 
limitations/restrictions.  Each  of  these  usage  rights  are  described  below. 

1.  Unlimited  rights  provides  the  Government  with  the  right  to  use,  duplicate,  release, 
or  disclose,  technical  data  or  computer  software  in  whole  or  in  part,  in  any  manner 
and  for  any  purpose  whatsoever,  and  to  have  or  permit  others  to  do  so  (DEARS). 

2.  Limited  rights  provides  the  Government  with  the  right  to  use,  duplicate,  or  disclose 
in  whole  or  in  part  fa*  the  Government,  with  the  express  limitation  that  the  com¬ 
puter  software  documentation  shall  not  be  used  to  prepare  the  same  or  similar 
computer  software  and  shall  not  be  released  outside  the  Government,  except  when 
needed  fcx*  emergency  repairs  and  for  disclosure  to  foreign  Governments  for 
informational  purposes  (DEARS). 

3.  Restricted  rights  applies  to  computer  software,  and  includes,  as  a  minimum,  the 
right  to:  use  the  computer  software  with  the  computer  for  which  it  was  acquired,  in¬ 
cluding  use  at  any  Governmental  installation  to  which  the  computer  may  be 
transferred  by  the  Government;  use  computer  software  with  a  backup  computer  if 
the  computer  for  which  it  was  acquired  is  imperative;  copy  computer  software  for 
safekeeping  or  backup  purposes;  and  modify  computer  software  or  combine  it  with 
other  software  (DEARS). 

4.  Government  Puipose  License  Rights  (GPLR)  gives  the  Government  the  right  to  use, 
duplicate,  or  disclose  technical  data  (applies  to  computer  software  under  the  Small 
Business  Innovation  Research  (SBIR)  program),  in  whole  or  in  part,  and  in  any 
manner,  for  Government  puiposes  only,  and  to  permit  others  to  do  so  for 
Government  puiposes  only  (DEARS). 

The  word  "Govemment-Off-The-Shelf  (GOTS)"  is  a  common  term  that  could  refer  to  a  number 
of  types  of  rights.  It  is  best  to  explain  what  rights  are  referred  to  when  using  the  term  "GOTS". 

There  seems  to  be  little  confusion  as  to  the  usage  of  commercial  products  (i.e.,  they  only  can 
be  copied  for  backup  puiposes).  Shareware  Components  (usually  code)  should  be  examined 
to  determine  what  the  user’s  responsibilities  are  for  distribution,  use  or  modification.  No  matter 
what  level  of  rights  are  associated  with  the  component,  the  library  is  obligated  to  supply  that 
information  to  the  users. 

The  main  concerns  regarding  intellectual  property  rights  in  the  context  of  managing  a  reuse 
library  are:  obtaining  the  appropriate  rights  infinmation  from  the  supplier,  ensuring  that  the 
component  is  submitted  to  the  library  marked  properly  and  that  the  user  is  made  aware  of  the 
status  of  the  original  owner’s  rights,  both  in  the  original  component  and  any  derivative  work. 
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2  J  UabiUty 

Liability  can  be  based  on  contracts,  statutes  and  tort.  Liability  in  contracts  can  result  when  one 
party  breaches  a  term  of  the  contract  (note:  contract  liability  includes  warranties).  Of  coxirse,  if 
laws  (statutes)  are  not  obeyed,  one  can  be  at  risk  to  pay  penalties  as  covered  imder  law.  Based  on 
the  conunon  law  of  tort,  one  has  a  duty  to  provide  a  certain  "standard  of  care"  to  another  when 
it  is  expected  of  them  (note:  tort  liability  includes  strict  liability,  e.g.,  unreasonably  dangerous 
product)  [4].  As  the  library  engages  in  more  varied  activities,  it  assumes  greater  risk  of  claims 
for  mistakes/errors  in  its  activities  and  in  the  reusable  software  components  contained  in  the 
library.  If  the  level  of  risk  is  determined  to  be  unacceptable,  the  library  can  draft  agreements 
with  its  suppliers  and  users  to  include  provisions  which  will  help  reduce  the  risk  [4].  In  addition 
to  adding  legal  protections  in  agreements,  liability  can  be  reduced  by  the  supplier  by  incorpOTating 
a  product  liability  strategy  via  quality  control  mechanisms.  Strict  liability  covers  damage  caused 
by  products  that  are  unreasonably  dangerous,  or  that  contains  unreasonably  dangerous  defects. 
Thus,  a  supplier  could  increase  quality  control  processes  and  mechanisms  to  reduce  defects  [5]. 

One  concern  regarding  liability  in  the  context  of  a  reuse  library  is  making  sure  applicable 
laws  are  followed  by  the  library  staff.  Some  important  laws  include,  but  are  not  limited  to 
copyright  laws,  patent  laws,  FAR,  DFARS,  Freedom  of  Information  Act  (FOIA),  and  Export 
Control  Laws.  Library  staff  must  take  care  in  following  the  library’s  policies  and  procedures 
in  performing  duties,  such  as,  evaluating  compomnts,  adding  components  to  the  library,  and 
implementing  security  procedures.  Additional  concerns  regarding  liability  are  informing  the 
users  of  applicable  policies  and  carefully  drafting  and  negotiating  agreements  with  suppliers  and 
users. 
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3  APPLYING  AGREEMENTS  TO  THE  CARDS  LIBRARY 

It  is  important  fa*  the  library  to  delineate  its  roles,  responsibilities  and  relationships  with  all 
participants  involved  in  the  library.  This  information  should  be  documented  in  the  library’s 
policies  and  procedures  and  in  turn  made  easily  accessible  to  all  participants.  Once  policies  and 
procedures  are  published,  it  is  extremely  important  for  the  library  to  follow  them.  If  the  library 
claims  that  they  are  conducting  business  one  way.  and  a  customer  relies  on  that  information,  but 
the  library  actually  conducts  business  in  a  different  manner,  the  library  could  be  held  responsible 
ftx  any  damages  inflicted  upon  that  customer. 

Thus  policies  and  procedmes  should  be  written  and/or  negotiated  to  reflect  pertinent  issues 
regarding  the  following  relationships:  Library-Supplier,  Library-User,  and  Library-Library  (if 
library  interoperability  applies).  Some  of  these  issues  could  be  impcsrtant  to  just  a  supplier,  user 
(x*  other  libraries.  On  the  other  hand,  other  issues  could  be  primarily  applicable  to  one  party 
(e.g.,  supplier),  but  have  secondary  application  to  another  party  (e.g.,  user). 

Whether  an  agreement  is  between  the  library  and  supplier,  library  and  user,  or  the  library  and 
another  library,  it  should  reflect  consensus  between  the  parties  involved  over  the  essential  terms 
and  conditions  of  the  library.  All  processes  and  procedures  should  either  be  defined  in  the 
agreement  or  referenced  if  already  addressed  in  another  document.  Business  and  legal  counsel 
should  be  sought  to  write,  negotiate  and  implement  reuse  library  agreements.  Clauses  outlining 
common  terms  and  conditions  of  agreements  are  described  below. 

Any  agreement  should  specifically  and  concisely  describe  the  purpose,  and  perhaps  the  scope  of 
the  agreement. 

Participants 

The  parties  involved  in  the  agreement  should  be  specifically  listed.  This  could  be  limited  to  the 
name  of  the  organization,  rather  than  an  individual’s  name.  Included  with  this  should  be  point 
of  contact  information.  Agreements  must  be  signed  by  two  legal  entities.  Fot  Government 
Owned-Govemment  Operated  library’s  accepting  components  from  Government  agencies,  a 
^femorandum  of  Agreement  or  Memorandum  of  Understanding  would  suffice.  For  Government 
Owned-Contractor  Operated  (GOCO)  libraries,  formal  agreements  would  be  necessary  whether 
the  supplier  is  a  commercial  vendor  or  a  Government  agency.  For  user’s  applying  fa*  an  account, 
a  statement  of  responsibilities,  or  a  registration  f(xin  would  suffice,  which  would  be  signed  by 
the  user  only.  A  clause  stating  that  the  person  signing  the  agreement  has  the  authority  to  do 
so  may  help  reduce  problems  later.  With  this  clause,  a  party  could  not  claim  at  a  later  time 
that  they  do  not  have  to  comply  with  the  terms  and  conditions  of  the  agreement,  because  the 
signatory  was  not  authorized. 

Pertinent  Dates 

Terms  fw  when  the  agreement  is  effective  and  when  the  agreement  terminates  should  be  explicit. 
The  effective  date  clause  could  state  that  the  effective  date  is  a  certain  number  of  days  after 
the  last  person  signs  the  agreement  or  could  specifically  indicate  the  effective  date.  Providing 
a  termination  or  expiration  date  is  a  practical  way  to  end  a  party’s  obligation.  However,  the 
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party’s  can  also  agree  to  terminate  the  agreement  under  certain  circumstances  (e.g.,  a  component 
is  no  longer  being  maintained  by  the  supplier;  the  library  modifies  its  library  model,  and/or 
the  component  does  not  fit  into  the  domain  and  will  not  pass  the  evaluation).  Whatever  these 
circumstances  are,  they  should  be  explicitly  defined  in  the  agreement.  A  distinction  must  be 
made  between  "terminating"  and  "rescinding".  When  an  agreement  is  terminated,  each  party 
must  complete  any  outstanding  responsibilities.  When  an  agreement  is  rescinded,  it  is  as  though 
the  agreement  never  took  place,  and  the  parties  must  return  (e.g.,  return  a  component,  return  a 
fee  paid)  anything  received  from  the  other  party. 

Definitions 

The  parties  involved  in  an  agreement  may  define  terms  differently.  This  is  especially  true  in 
the  software  reuse  area.  For  example,  the  term  "evaluation"  may  have  different  meanings  to 
different  parties.  Thus  it  is  important  to  define  any  term  that  is  not  easily  understood,  terms  that 
may  have  ambiguous  meanings,  and  terms  having  a  major  importance  to  the  agreement,  such 
as  evaluation,  qualification,  support,  and  maintenance  [6].  If  the  parties  agree  on  the  definitions 
befcnehand,  any  potential  disagreements  can  be  deterred  [7]. 

Roles  and  Responsibilities 

The  roles  and  responsibilities  required  for  each  party  should  reflect,  at  a  minimum,  issues  for 
evaluating  components  (supplier  agreements),  submitting  components  (supplier  agreements), 
withdrawing  components  (user  agreements),  security  (supplier  and  user  agreements),  and 
maintenance  (supplier  and  user  agreements).  Documenting  these  responsibilities  will  make  it 
clear  to  each  party,  what  is  required  from  them.  These  issues  are  discussed  in  detail  in  Section 
4,  Supplying  Components,  Section  5,  Extracting  Components,  and  Section  6,  Interoperability. 

Liability  Reduction  Clauses 

Qauses  can  be  added  specifically  to  reduce  the  library’s  liability.  These  clauses/statements 
include,  but  are  not  limited  to: 

•  warranty 

•  hold  harmless 

•  indemnification 

•  disclaimer 

•  non-  disclosure 

•  release 

•  dispute 

However,  no  matter  what  statements  or  clauses  are  put  into  an  agreement  to  limit  someone’s 
liability,  that  liability  can  not  be  limited  if  grc»s  negligence  is  present  or  if  processes  and 
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procedures  identified  are  conducted  in  a  subjective  manner  [1].  As  discussed  above,  the  library 
should  be  cautious  when  adding  any  liability-reducing  clause,  since  they  do  not  want  to  imply 
any  incompetencies  on  the  part  of  the  library. 

A  software  warranty  clause  specifies  the  terms  under  which  the  supplier  has  a  duty  to  replace, 
correct  defective  software,  or  refimd  any  fees  charged  [7].  The  result  is  to  limit  the  liability  of 
the  component  supplier.  This  clause  can  also  be  used  by  the  supplier  to  terminate  his/her 
duty  to  supptHt,  maintain  or  fix  software  that  has  been  changed  without  their  consent  [7]. 
Warranty  is  usually  not  negotiable  for  Commercial-Off-  The-Shelf  (COTS)  products.  For 
a  Government  develtqjed  product,  any  warranty  terms  would  be  negotiated  at  the  time  of  the 
original  contract  Thus,  to  limit  its  liability,  the  library  should  ensure  that  whatever  warranty 
statements  are  provided  by  the  supplier  are  made  easily  accessible  to  the  user. 

A  hold  harmless  provision  could  be  added  to  protect  the  library  against  possible  future  claims. 
It  is  a  written  assumption  of  liability  by  one  party,  where  he/she  agrees  to  protect  another  party 
from  anticipated  claims  [4]. 

An  indemnification  clause  is  a  written  promise  to  secure  against  loss  (m*  damage  that  may 
occur  in  the  future  and  can  set  the  compensation  for  financial  obligation  and  responsibilities 
[4].  For  example,  a  library  could  state  "The  Library  places  full  reliance  on  the  supplier’s 
representations  and  is  not  responsible  for  any  unauthorized  use  (by  user)  resulting  from  improper 
or  erroneous  certifications  tx  lack  of  markings".  This  statement  is  telling  the  supplier  that  it  is 
their  responsibility  to  supply  the  correct  copyright,  and  to  mark  the  component  ^propriately. 
Further,  it  says  that  if  the  supplier  does  not  submit  the  correct  information  ncx  mark  the 
component  pr(^>erly,  and  if  a  user  infringes  upon  the  copyright,  it  is  not  the  library’s  fault. 

Disclaimers  are  used  as  a  method  of  controlling  potential  liability  by  reducing  the  number  of 
situations  for  which  an  entity  can  be  held  to  have  breached  a  duty  or  contract  [4]. 

A  non-disclosure  provision  requires  a  party  not  to  release  particular  information  to  third  parties. 
A  supplier  may  want  the  library  to  include  this  type  of  clause  to  govern  the  dissemination  of 
evaluation  results  of  components  not  accepted  into  the  library.  This  clause  can  also  be  used  to 
protect  trade  secrets,  marketing  techniques  and  strategies.  It  can  also  include  provisions  that  the 
buyer  must  pay  damages  for  the  improper  or  unauthorized  use  of  the  software  or  information. 

A  release  gives  permission  to  the  other  party  to  use  certain  information  provided  to  them,  for  a 
certain  transaction  to  proceed,  (x  f(X  a  certain  result  to  occur.  A  standard  release  might  be  for 
"any  ex  all  claims  which  might  arise  by  reason  of  use  or  redistribution  ..."  of  reusable  software 
components  from  the  library  [4]. 

A  dispute  clause  can  provide  a  mechanism  (how  conflicts  will  be  resolved  and  by  whom)  for 
resolving  any  disputes  that  may  arise  in  the  future.  If  disputes  do  arise,  this  clause  can  specify 
that  the  parties  agree  to  settle  in  arbitration  rather  than  or  before  going  to  coiut  [1].  It  also  can 
specify  that  the  resolution  will  be  subject  to  the  laws  of  a  particular  jixisdiction  [3]. 

Ctxrespondence 
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It  is  also  a  good  idea  to  include  in  any  agreement  how  crnrespondence  or  notices  will  be  sent 
(e.g.,  facsimile,  electronic  mail  or  overnight  mailing  service),  as  well  as  when  they  are  effective 
(iqxm  receipt  or  upon  mailing). 

Headings 

In  some  agreements,  the  paragrt^h  ot  clause  headings  used  may  be  misleading,  ambiguous  or 
not  indicate  what  the  clause  actually  refers  to.  A  statement  can  be  added  that  states  that  the 
headings  used  in  the  agreement  are  for  reference  purposes  only  and  should  not  be  considered  as 
part  of  the  agreement.  For  example,  the  heading  may  say  "Warranties",  but  the  paragraph  may 
actually  disclaim  any  warranties  [3]. 

Assignment 

An  "Assignment"  clause  should  be  added  for  both  parties  (library  and  suppliers).  Under  the 
assignment  clause,  the  agreement  is  automatically  transferred  to  a  new  party  (e.g.,  new  prime 
contractor  for  a  library  or  new  owner  of  software)  without  obtaining  new  signatures.  However, 
either  party  can  terminate  the  agreement  if  they  do  not  want  to  do  business  with  the  new  party. 
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4  SUPPLYING  COMPONENTS 
4.1  Implementing  Supplier  Agreements 

Since  the  library  accepts  components  from  various  sources,  the  supplier  agreements  must 
reflect  the  needs  and  concerns  of  each  type  of  supplier.  These  supplio^  include;  Government 
agencies  submitting  Government  develq)ed  components;  Govonment  agencies  submitting 
c(Hitract(X‘  develqied  components;  a  contract^'  submitting  Contractor  developed/Govemment 
fimded  components;  and  a  vendor  submitting  commercial  components.  Each  of  these  will  be 
concerned  with  the  libraries  policies  and  procedures  regarding  component  submittal,  component 
evaluation,  component  withdrawal,  security  and  maintenance.  Each  of  these  are  described  below. 

Although  instructions  for  submitting  components  to  a  library  are  obviously  {y>plicable  to  the 
supplier,  some  infomation  ultimately  determines  how  the  components  can  and  should  be 
implemented  by  the  end-user.  Guidelines  (x*  procedures  should  be  developed  to  give  the  supplier 
explicit  instructions  as  to  what  information  is  required  or  needed  by  the  library  to  evaluate  the 
component,  incoiporate  the  component  into  the  library  model  and  to  distribute  the  component 
to  its  users,  and  for  the  end-users  to  re-use  the  component  Providing  explicit  instructions 
befne  components  are  submitted  will  help  reduce  any  misimderstandings  and  help  resolve  any 
disagreements  which  may  arise  at  a  later  date.  In  fact  the  library  may  want  the  supplier  to 
agree  to  comply  with  the  submittal  procedures  and  in  turn,  the  library  could  agree  to  conduct 
all  evaluations  in  accordance  with  the  documented  procedures.  On  the  other  hand,  the  supplier 
should  be  ^ven  the  freedom  to  submit  additional  component  infomation. 

The  library  should  outline  exactly  how  the  supplier  should  submit  the  component,  what  should 
be  submitted  with  the  component  and  to  whom  it  should  be  sent.  This  includes  the  format, 
technical  descr4>tive  information,  mailing  or  e-mail  address,  and  details  on  intellectual  property 
rights,  distribution  and  usage. 

Formats  of  the  components  and  related  descriptive  information  (including  documentation,  test 
results,  installation  procedures,  etc.)  are  important  fa*  the  library  to  conduct  its  business.  In  mder 
to  reduce  any  misunderstandings  and  re-submittals  of  components,  the  library  should  include 
precise  formats  that  are  acceptable  (electronic  formats,  such  as  postscript;  media  formats,  such 
as  UNIX  compatible  3  1/2"  flqjpy  disk). 

Keep  in  mind  that  in  some  cases  the  supplier  may  be  a  conunercial  vendor  and  in  other  cases 
the  supplier  may  be  another  Government  agency,  a  Government  contracttx’  or  even  a  perspective 
Government  contractm*.  Other  components  that  are  submitted  to  the  library  may  be  public  domain 
or  even  shareware.  Each  of  these  cases  may  require  the  supplier  to  submit  different  information 
and  cause  the  library  to  treat  the  component  differently. 

The  supplier  should  identify  whetho*  or  not  there  is  a  copyright  ot  patent,  to  whom  it  was 
issued  and  when.  This  certainly  would  not  be  a  problem  with  commercial  products.  As  we 
know,  developers  of  commercial  software  products  take  great  care  in  relaying  this  information 
via  various  avenues,  such  as  shrink  wrap  licenses  and  on-soeen  notices. 
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However,  if  the  component  was  developed  imder  a  Government  contract  and/or  submitted  by 
someone  other  than  the  (Higinal  developer,  this  information  may  not  be  readily  available.  For 
components  developed  under  a  Government  contract,  there  are  different  Government  usage  rights 
possible:  unlimited,  limited,  restricted  and  GPLR.  (Note:  a  software  component  could  have 
different  rights  than  the  software  documentation,  depending  upon  whether  the  FAR  or  DFARS 
apply).  Again,  the  library  must  carefully  keep  track  of  this  data,  making  sure  the  component  and 
associated  data  are  marked  properly  and  the  information  easily  available  to  users.  It  is  impotant 
to  note  again  that  the  contractor  who  developed  the  component,  regardless  of  the  level  of  usage 
rights,  still  holds  the  copyright.  Government  documentation  may  have  distribution  limitations 
based  on  the  type  of  audience  allowed  to  view  it  (such  as:  Government  Only,  Government  and 
its  contractors.  General  Public,  DoD  only,  DoD  and  its  contractors,  etc.).  In  this  case  the  library 
is  responsible  f(x  making  sure  the  each  dociunent  is  distributed  to  the  correct  audience.  Thus, 
the  library  must  keep  track  of  whether  the  user  is  a  DoD  or  Government  employee,  DoD  or 
Government  contractor,  and  so  on. 

A  component  that  is  "shareware"  (usually  code)  does  not  necessarily  give  the  user  the  right  to 
modify,  distribute,  copy  or  use  it  freely.  These  components  should  be  examined  by  the  library 
to  determine  restrictions  or  limitations  for  distribution,  use  and  modification,  if  any. 

Warranty  information  should  also  be  kept  track  of  and  distributed  with  the  component,  no  matter 
what  Government  usage  rights  are  attached  to  it,  who  owns  the  copyright  or  who  submits  the 
component. 

The  accuracy  of  component  usage  and  distribution  restrictions  should  be  verified  so  that  the 
library  will  not  be  held  responsible  for  distributing  misleading  information  or  for  not  honoring 
copyrights  or  Government  usage  rights  laws.  However,  if  the  library  were  to  verify  all  data 
submitted  for  all  components,  they  would  be  in  the  business  of  verification  rather  than  that  of 
managing  a  library  and/or  domain.  On  the  other  hand  enough  information  should  be  given  by 
the  supplier  so  that  the  end  user  could  verify  the  data  if  need  be.  Thus,  to  protect  the  library  and 
save  it  from  verifying  all  data  for  all  components,  they  can  have  the  supplier  put  in  writing  that 
the  data  they  are  submitting  is  correct  and  complete.  This  is  probably  simpler  for  commercial 
products,  since  there  is  usually  just  one  party  to  interact  with,  but  may  be  more  difficult  fa* 
components  developed  with  Government  funds.  Similar  to  verification  of  the  correcmess  and 
accuracy  of  the  data,  the  library  can  protect  i^lf  further  by  having  the  submitter  certify  that 
they  are  indeed  authorized  to  submit  the  component 

If  component  submittals  are  not  initiated  by  the  developer,  but  are  searched  for  and  acquired  by 
the  library  itself,  greater  care  must  be  taken  to  make  sure  the  rights,  distribution  and  usage,  and 
warranty  data  is  located  and  accuracy  is  verified. 

Evaluation  and  Acceptance  of  Components 

Since  evaluation  results  can  have  an  impact  on  the  component  developer’s  reputation,  the 
suppliers  should  be  informed  up  front  as  to  what  the  evaluation  oiteria  are  so  they  can  agree 
to  them.  The  evaluation  criteria  should  also  include  the  "minimal  acceptance  level".  Suppliers 
may  want  to  know,  and  even  approve  of,  how  those  results  can  be  disseminated  and  to  whom, 
especially  if  the  results  are  negative.  Also,  it  may  be  more  valuable  to  a  user  of  a  component 
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if  the  supplier  validates  the  results  of  any  evaluation.  Having  the  suppliers  agree  to  them 
beforehand  will  help  reduce  any  possible  problems  later.  If  the  suppliers  do  not  agree  with 
the  criteria,  then  the  library  and  supplier  can  either  negotiate  to  makes  changes  or  the  supplier 
would  determine  not  to  submit  the  component,  or  the  library  could  decide  not  to  even  evaluate 
the  component.  Thus  the  library  must  be  careful  to  provide  up  to  date  evaluation  oiteria  and 
acceptance  procedures  to  both  the  supplier  and  users.  For  components  that  are  not  approved, 
the  supplier  may  want  to  modify  and  re-submit  the  component.  The  library  should  also  have 
precise  policies  and  procedures  for  whether  a  supplier  can  re-submit  a  component,  how  many 
times  they  are  allowed  to  do  so  and,  if  applicable,  the  associated  costs. 

If  feedback  or  comments  on  a  component  are  requested  from  a  user,  the  library  may  also  consider 
forwarding  the  comments  to  the  supplier. 

Suppliers  should  be  made  aware  of  security  provisions  since  they  may  require  certain  procedures 
to  be  in  place  before  they  submit  components  to  the  library.  In  fact,  this  could  be  a  selling  point 
fcH-  the  library.  The  security  process  should  include  specific  procedures  for  limiting  access  to 
authorized  users,  ensuring  the  integrity  of  data,  and  protecting  and  managing  use  of  licensed 
software.  In  addition,  the  procedures  could  also  cover  how  the  library  stores,  organizes  and 
allows  access  to  components  and  other  data,  such  as  evaluation  criteria  and  results. 

All  participants  involved  in  a  software  reuse  program  would  be  interested  in  component 
maintenance  policies  and  procediues.  The  library  would  want  to  know  which  components  it  is 
responsible  for  maintaining  and  which  components  the  supplier  would  maintain.  For  supplier 
maintained  components,  especially  COTS  products,  the  library  would  also  need  a  version  control 
mechanism  that  includes  informing  users  of  changes  or  upgrades  to  components.  This  may  even 
be  a  negotiated  item  in  an  agreement. 

4,2  Supplier  Agreements 

Three  sample  supplier  agreements  that  address  the  above  issues  are  presented  in  the  follovdng 
3  sections.  Each  addresses  different  issues  which  are  present  with  different  types  of 
suppliers.  These  sample  agreements  address  the  vendors  submitting  a  commercial  component, 
a  Govoiunent  agency  submitting  a  component,  and  a  Contractor  submitting  a  Government 
sponsored  component.  In  some  places  there  are  specific  notes  to  the  CARDS  Library  staff 
indicating  steps  that  need  to  be  taken.  These  notes  are  indicated  in  italicized-bold  font.  The 
premise  of  these  agreements  is  that  the  supplier  initiates  component  submittal,  which  does  not 
currently  occur  in  the  operating  procedures  of  the  CARDS  library.  There  are  also  other  topics  in 
these  agreements  that  require  policy  decisions  by  the  CARDS  Library  (For  recommended  policy 
changes,  see  [1]  and  [2]). 
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4J.1  Vendor  Supplies  Component 

AGREEMENT  FOR  ACCEPTANCE  OF  COMPANY  X’S  PRODUCT  COMPONENT  INTO 
THE  CARDS  LIBRARY 

This  is  an  agreement  between  Unisys  Government  Systems  (or  whichever  entity  operates  the 
Ubraryh  the  Operator  of  the  CARDS  Library  (referred  to  as  the  CARDS  Library  Operator  in  the 
renuunder  of  this  agreement),  and  Company  X  (hereafter  referred  to  as  "supplier").  (Note:  add 
maUing  and  paying  addresses  here  and  or  inter  in  the  agreement) 

1.  Purpose 

This  agreement  describes  the  terms  and  conditions,  including  responsibilities  of  the  parties,  for 
qualifying,  accepting  and  using  COMPANY  X’S  SOFTWARE  PRODUCT  UNIQUE  within  the 
CARDS  library  (define  what  the  library  consists  of)  environment  and  other  libraries  which  may 
have  interoperability  agreements  with  CARDS.  The  parties  agree  the  product  UNIQUE  (referred 
to  as  "component"  in  the  balance  of  this  agreement)  may  be  accessed  by  libraries  other  than 
CARDS  and/or  their  authorized  users.  (Note:  This  indicates  components  that  are  accessed 
by  ASSET  and  DSRS  via  the  interoperabiUty  index.)  These  libraries  and  users  have  agreed 
to  comply  with  CARDS  use  provisions  and  any  conditions  for  use  clearly  represented  for  the 
component 

2.  Term  of  Agreement 

This  agreement  is  effective  (month/day/year)  and  shall  remain  in  effect  through  (month/day/year), 
unless  terminated  (see  12  below)  or  superseded  by  either  party  or  mutual  agreement. 

3.  Definitions 

a.  Commercial-off-the-shelf  (COTS)  Components  and  Documentation.  COTS  items  are  those 
regularly  used  in  the  course  of  normal  business  operations  for  otho*  than  government  purposes. 
These  have  been  sold  or  licensed  to  the  general  public;  ot,  have  not  been  sold  or  licensed, 
but  have  been  offered  fcr  sale  or  license  to  the  general  public;  are  not  yet  available  in  the 
commercial  marketplace,  but  will  be  within  the  term  of  this  agreement  COTS  components  and 
documentation  have  been  developed  at  private  expense,  or,  otherwise  determined  to  be  private. 

b.  Government-off-the-shelf  (GOTS)  Components  and  Documentation.  GOTS  items  are 
those  which  have  been  furnished  and  accepted  under  a  federal  government  contract  GOTS 
components  and  documentation  have  been  developed  at  government  expense;  or,  have  otherwise 
been  provided  to  the  government  with  specific  license  or  assignment  rights. 

c.  Library  Model.  As  used  in  this  agreement  library  model  is  the  representation  of  the  CARDS 
library  environment  as  described  in  the  CARDS  Library  Model  Document. 

d.  Support.  SuppcHt  includes  any  and  all  services,  data,  and  documentation  necessary  to  qualify 
the  component  The  level  of  suppmt  is  agreed  as  not  less  than  XX  hours  of  engineering  services 
(specifically  skill  categtxy,  such  as  "senior  software  engineer")  during  the  component  submission 
or  resubmission  and  qualification  periods  contemplated  by  paragrq>hs  4  and  5  of  this  agreement 
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e.  Section  Titles.  Titles  or  captions  in  this  agreement  are  fw  reference  purposes  only  and  are 
not  meant  to  be  used  to  define,  limit  or  describe  the  scope  or  intent  of  this  agreement. 

4.  Coinponent(s)  Submission,  Evaluation  and  Qualification  Requirements 

a.  The  supplier  agrees  to  comply  with  the  component  submission  requirements  of  the  CARDS 
library  as  described  in  the  CARDS  Library  Development  Handbook  (dated  mm/dd/yy)  and  Com¬ 
ponent  Submittal  Guidelines.  The  component(s)  will  be  submitted  with  sufficient  documentation 
to  allow  independent  evaluation  by  the  CARDS  library.  Sufficient  unrestricted  supporting  docu¬ 
mentation  shall  be  provided  to  allow  subscribers  to  ascertain  component  utility  fa*  their  intended 
applications.  Company  X  agrees  to  provide,  at  no  cost,  any  additional  support,  as  defined  in 
paragraph  3.d  above,  which  may  be  necessary  to  evaluate  the  component(s)  and  related  docu¬ 
mentation. 

b.  The  supplier  will  provide  a  recommendation  regarding  the  appropriate  component  class  for  the 
submitted  component(s)  within  the  context  of  the  Library  model.  The  CARDS  Library  Operato* 
retains  the  right  to  assign  the  ultimate  classification. 

c.  The  Library  represents  it  will  conduct  all  evaluations  in  accordance  with  the  procedures 
described  in  the  Library  Development  Handbook.  Documentation  results  will  be  in  the  fcxmat  and 
include  the  content  described.  The  CARDS  Library  Operatcx*  personnel  performing  evaluation 
and  qualification  are  knowledgeable  in  the  component(s)  class(es)  involved. 

d.  While  the  CARDS  Library  Operatcx  retains  the  absolute  right  to  ultimately  determine 
whether  a  component  is  suitable  for,  accepted,  and  integrated  into  the  library  model,  the 
supplier  will  be  provided  an  opportunity  to  comment  on  the  evaluation  and  qualification 
results.  The  comment  period  will  be  for  30  days,  (the  tibrary  needs  to  specify  the  time 
Umit)  and  occur  prior  to  acceptance  into  the  library.  The  Library  is  under  no  obligation 
to  change  its  evaluation  and  qualification  results  after  review  and  consideration  of  the  supplier’s 
comments.  Those  components  accepted  into  the  library  will  include  both  the  Library  and 
supplier  comments  as  well  as  any  submitted  documentation  necessary  to  adequately  describe  the 
components).  Components,  evaluation  results,  comments  and  supporting  documentation  (for 
accepted  components)  will  be  available  on-line  to  all  authorized  Library  Subscribers.  Any  future 
objection  to  the  dissemination  of  component  evaluation  results  will  be  cause  for  terminating  this 
agreement  and  removing  the  components)  from  the  library.  (Note:  It  has  been  recommended 
that  the  tibrary  obtain  supptier  comments  when  feasibk  and  to  make  them  available  to  the 
account  holders  [1]  [2].  However,  the  tibrary  needs  to  determine  the  associated  procedures 
in  doing  so.  This  includes  setting  a  time  limit  and  making  these  comments  available  on-line 
to  users.  In  addition,  the  tibrary  may  want  to  offer  a  reconsideration  qfter  some  period  to 
consider  additional  information,  or,  experience  with  the  component;  and,  maybe  withdraw 
earlier  comments  or  annotate  with  new  comments.) 

5.  Component  Resubmission,  Evaluation,  and  Qualification 

a.  Resubmission  of  Previously  Disapproved  Components.  Components  not  approved  after 
formal  evaluation  and  qualification  testing  must  be  formally  resubmitted  if  the  supplier  wishes 
to  have  the  component  reconsidered.  The  supplier  will  include  identification  of  the  prior 
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submission(s)  and  all  documentation  relating  to  the  earlier  disapproval(s).  The  resubmission 
documentation  will  include  not  only  that  required  for  new  component  submission  but  also 
identification  of  any  changes  made  to  the  component(s)  since  the  last  submission  and  a  supplier 
analysis  of  why  it  believes  the  basis  for  lack  of  previous  acceptance  has  been  removed.  The 
analysis  will  include  an  item  by  item  accounting  of  the  Library’s  previous  findings. 

b.  Component  Upgrades.  Component  upgrades  are  considered  new  components.  These 
win  follow  the  submission  requirements  fcx  new  components  as  a  prerequisite  for  consideration 
by  the  Library  for  evaluation  and  qualification.  The  supplier  will  include  identification  of  the 
prior  submission(s)  and  all  documentation  relating  to  prior  dispositions  of  the  components.  The 
submission  package  will  include  a  summary  identifying  the  component(s)  modifications:  the 
purpose  of  the  modifications;  and,  any  supplier  perceived  impact  on  prior  Library  evaluation  and 
qualification  findings. 

c.  Resubmission  Limits.  The  library  reserves  the  right  to  limit  resubmissions  or  upgrades  to  a 
reasonable  number  within  any  period  of  time.  The  determination  of  ’reasonable’  is  at  the  sole 
discretion  of  the  library. 

(Note:  It  was  recommended  that  the  Ubrary  determine  the  policy  and  procedures  for  suppliers 
to  re-submit  component.  This  should  include  the  definition  of  ^'upgrades'*  and  limits  on 
re-submission.  See  [1]  and  [2].) 

6.  Component  Baseline 

The  library  model  will  maintain  only  the  latest  q}proved  version  of  the  component  and  supporting 
documentation  currently  in  CARDS  possession.  CARDS  will  maintain  older  versions  in  its 
possession  off-line  and  will  provide  an  off-line  retrieval  process.  (Note:  A  component  version 
policy  needs  to  be  addressed  by  the  library.) 

7.  Ownership,  Rights  and  Limitations 

a.  By  executing  this  agreement,  the  supplier  certifies  it  has  accurately  represented  the 
components)  with  respect  to  existing  domestic  and/or  international  proprietary;  copyright; 
patent;  trademark;  federal  government  unlimited,  limited,  restricted  and/or  government  pxirpose 
rights,  specifically  including  any  rights  (x  limitations  regarding  Foreign  Military  Sales,  federally 
sponsored  International  agreements,  or  in  the  case  of  restricted  rights,  specifically  stating 
any  additional  rights  granted  over  the  minimum  rights.  The  supplier  will  expressly  describe 
any  limitations  on  reuse  of  the  component(s)  and  insert  appropriate  markings.  Any  special 
limitations/granting  of  rights  such  as  use  by  educational  institutions;  direct  sales  of  the  component 
(whether  by  itself  or  inc(xp<xated  within  a  product)  to  foreign  governments  or  direct  foreign 
commercial  sales  shall  be  expressly  identified. 

b.  The  library  places  full  reliance  on  the  representations  addressed  in  paragrtqsh  7. a.  and  is  not 
responsible  for  any  unauthorized  use  resulting  from  improper  or  erroneous  certifications  or  lack 
of  markings. 

c.  All  authorized  users  will  be  notified  of  all  supplier  disclosures  regarding  ownership,  rights 
and  limitations  prior  to  accessing  a  component 
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8.  Fees 

The  library  may  in  the  future  charge  fees  for  subscribers  accessing  components  witliin  the 
Library  model.  The  supplier  recognizes  and  agrees  any  future  fees  are  Library  compensation 
and  it  waives  any  claim  to  the  fees  collected.  (Note:  The  Library  needs  to  make  a  decision  on 
this  issue.) 

9.  Subscriber  Access  Rules  for  Component  Examination  and  Extraction 

a.  The  Library  requires  potential  users  to  complete  the  CARDS  Library  Account  Holder 
Registration  Ftxm,  which  indicates  the  account  holder’s  roles  and  responsibilities,  prior  to 
becoming  an  authorized  subscriber  and  gaining  access  to  the  CARDS  Library.  The  supplier 
agrees  it  has  examined  this  form  and  accepts  the  adequacy  of  the  protection  afforded  by  user 
execution. 

b.  Subscribers  include  not  only  CARDS  library  account  holders  but  also  those  from  ASSET 
and  DSRS.  The  supplier  recognizes  and  agrees  all  subscribers  have  access  to  the  component, 
consistent  with  the  terms  of  this  agreement.  (Note:  A  supplier  may  want  to  restrict  its  license  to 
just  the  CARDS  site  {single  or  multi-user}  versus  multi-site,  multi-user  licenses  for  the  actual 
component  itself,  must  be  discussed  and  then  limited  if  full  Tri-Lateral  Interoperability 
access  is  not  desired  by  the  supplier.) 

10.  Feedback  (where  desired) 

The  library  will  provide  subscriber  feedback,  as  it  may  be  obtained,  to  the  supplier  upon 
request,  but  not  more  frequently  than  semi-annually  (Note:  the  library  needs  to  determine 
the  appropriate  timeframe).  The  library  will  not  edit  or  comment  on  the  feedback  in  any  way, 
nor  be  responsible  for  its  dissemination  (authorized  or  unauthorized).  Feedback  may  be  provided 
by  all  Tri-  Lateral  interoperability  subscribers  accessing  the  component.  The  records  will  include 
identity  of  subscribers  which  access  the  supplier  c<nnponent(s).  (Note:  It  was  recommended 
that  the  library  determine  the  poUcy  and  procedures  for  requiring  feedback  from  users  on 
supplier  components.  See  [I]  and  [2].) 

11.  Promotion  and  Advertising 

a.  Once  a  component  is  accepted  into  the  library  model,  the  supplier  may  promote  this  fact  and 
its  access  (within  the  scope  of  the  library)  vrithout  further  notice  to  the  library.  All  supplier 
promotion  and  distribution  of  materials  must  cease  as  of  the  date  of  expiration  or  terminations 
of  the  agreement  The  supplier  is  not  obligated  to  recover  existing,  distributed  matoials. 

b.  Acceptance  of  the  component  shall  not  be  constructed  as  an  endorsement.  Acceptance 
connotes  the  component  has  met  the  criteria  for  the  applicable  class  and  may  be  considered  for 
use  by  a  subscribn*  within  that  class.  All  promotional  material  shall  clearly  exhibit  a  legend  to 
this  effect. 

12.  Termination 

This  agreement  may  be  terminated  by  either  party  for  any  reason  by  furnishing  a  notice  in  writing 
by  certified  mail  or  hand  carried.  This  notice  will  be  effective  30  days  after  receipt.  This 
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agreement  may  also  be  terminated  by  either  party  fa*  failure  to  comply  with  any  of  the  material 
requirements  of  this  agreement.  Termination  will  not  affect  previously  authorized  component 
use  by  any  subscriber.  Termination  will  result  in  removal  of  the  component  from  the  library. 
The  library  will  retain  qualification  results,  supplier  comments,  and  submitted  documentation  for 
any  component  removed,  and  reserves  the  right  to  allow  subscriber  access  to  this  data.  (Note: 
A  termination  policy  needs  to  be  addressed  by  the  library.) 

13.  Assignment  of  Agreement 

Assignment  will  be  automatic  unless  this  agreement  is  first  terminated  in  writing  by  either  party. 
The  parties  agree  to  automatically  assign  this  agreement  to  successor  interests  when:  (1)  the 
current  (q>erator  of  the  library  sells  or  transfers  its  rights  and  interests  to  the  contract  for  library 
operation:  (2)  the  supplier  is  bought  out  or  sells  the  rights  to  its  components)  to  some  other 
entity.  The  library  reserves  the  right  to  terminate  the  agreement  with  any  successor  party. 

14.  Indemnification 

a.  The  supplier  indemnifies  the  library  against  any  user  misrepresentations;  Ulegal,  or,  otherwise 
inappropriate  uses  of  the  components  and  supporting  documentation  covered  by  this  agreement. 
The  supplier  recognizes  and  accepts  that  the  library  has  executed  user  agreements  in  good  faith 
and  exercised  reasonable  diligence  in  its  procedures  to  avoid  improper  or  prohibited  use  of 
components  and  documentation. 

b.  The  library  places  full  reliance  on  the  representations  addressed  in  paragraph  7. a.  and  is  not 
responsible  for  any  unauthorized  use  resulting  fi-om  improper  or  erroneous  certifications  or  lack 
of  markings. 

c.  CARDS  is  part  of  the  interqTerability  library  system  (currently  consisting  of  CARDS,  ASSET, 
and  DSRS).  The  supplier  has  reviewed  the  Memorandimi  Of  Understanding  for  Tri-Lateral 
Interoperability  and  agree  it  is  sufficient  to  protect  their  rights  and  interests. 

(A^ote:  Liability  for  gross  negligence  and  intentional  violation  of  license  agreements  by  the 
library  or  Us  stitff  is  not  protected  by  this  provision.) 

15.  Governing  Statutes 

This  agreement  is  subject  to  the  laws  of  the  state  of  YY  (add  the  state  in  which  Unisys 
is  incorptxrated.  If  an  entity  other  than  Unisys  operates  the  library,  enter  the  appropriate 
incorpOTating  state)  however,  the  parties  agree  to  submit  to  binding  arbitration  to  resolve  any 
disputes. 

16.  Points  of  Contact 

Each  party  shall  annually  provide  notice  to  the  other  of  its  principal  point  of  contact  for  the 
actions  and  responsibilities  under  this  agreement,  including  modifications  to  this  agreement 
(Note:  7  he  library  needs  to  make  a  decision  on  policies  and  procedures  regarding  points  of 
contact  data.) 

17.  Modifications  to  the  Agreement 
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Modifications  to  this  agreement  shall  be  accomplished  whenever  a  change  in  library  (^)erations. 
or  other  conditions  a^ecting  the  substance  of  the  agreement  occur,  subject  to  mutual  agreement 
of  the  parties. 

18.  Signature  Authority 

The  parties  executing  this  agreement  certify  they  are  authmized  by,  and  have  the  full  authority 
of  their  respective  m'ganizations  to  commit  to  its  terms  and  conditions  and  bind  the  parties  to  its 
fulfillment 

EXECUTED  THE _ DAY  OF _ ,  199  BY 

THE  LIBRARY _ 

THE  SUPPLIER _ 
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42^  Government  Agency  Supplies  Component 

AGREEMENT  FOR  ACCEPTANCE  OF  GOVERNMENT  AGENCY  Q’S  DEVELOPED 
(IN-HOUSE)  PRODUCT  COMPONENT  INTO  THE  CARDS  LIBRARY 

This  is  an  agreement  between  Unisys  Government  Systems  (or  whichever  entity  operates  the 
library),  the  Operator  of  the  CARDS  Library  (rererred  to  as  the  CARDS  Library  Operator  in 
the  remainder  of  this  agreement),  and  Government  Agency  Q.  (Note:  add  mailing  and  paying 
addresses  here  and  or  later  in  the  agreement) 

1.  Purpose 

This  agreement  describes  the  purpose,  terms  and  conditions,  including  responsibilities  of 
the  parties,  for  qualifying,  accepting  and  using  Government  Agency  Q’s  developed  software 
product  TAXPAYER  within  the  CARDS  Library  environment.  The  parties  agree  the  CARDS 
environment  included  current  and  future  library  interoperability  relationships  where  the  product 
TAXPAYER  (referred  to  as  "component"  in  the  balance  of  this  agreement)  may  be  accessed 
by  libraries  other  than  CARDS  and/m'  their  authorized  users  which  have  agreed  to  comply  with 
CARDS  use  provisions  and  any  conditions  for  use  clearly  represented  for  the  component.  (Note: 
This  indicates  components  that  are  accessed  by  ASSET  and  DSRS  via  the  interoperability 
index.)  The  parties  recognize  and  agree  the  component  TAXPAYER  has  been  developed  under 
(Specify  under  what  conditions  the  software  product  was  developed,  i.e..  Internally  fiuided  work 
using  agency  Operation  funds;  internally  developed  fcx-  another  government  customer  using  the 
customer  funds;  other  scenario)  and  is  included  in  the  CARDS  library  with  the  ownership  rights 
certified  by  Agency  Q  (and  its  sponsor,  the  (Agency  Name),  if  applicable). 

2.  Term  of  Agreement 

This  agreement  is  effective  (month/day/year)  and  shall  remain  in  effect  through  (month/day/year), 
unless  terminated  (see  12  below)  or  superseded  by  either  party  or  mutual  agreement. 

3.  Definitions 

a.  Commercial-off-the-shelf  (COTS)  Components  and  Documentation.  COTS  items  are  those 
regularly  used  in  the  course  of  normal  business  operations  for  other  than  government  purposes. 
These  have  been  sold  or  licensed  to  the  general  public;  or,  have  not  been  sold  <»’  licensed, 
but  have  been  offered  for  sale  or  license  to  the  general  public;  are  not  yet  available  in  the 
commercial  markeq)lace,  but  will  be  within  the  term  of  this  agreement  COTS  components  and 
documentation  have  been  developed  at  private  expense,  or,  otherwise  determined  to  be  private. 

b.  Government-off-the-shelf  (GOTS)  Components  and  Documentation.  GOTS  items  are 
those  which  have  been  furnished  and  accepted  under  a  fedo’al  government  contract  GOTS 
components  and  documentation  have  been  developed  at  government  expense;  or,  have  otherwise 
been  provided  to  the  government  with  specific  license  or  assignment  rights. 

c.  Library  Model.  As  used  in  this  agreement  library  model  is  the  representation  of  the  CARDS 
library  environment  as  described  in  the  CARDS  Library  Model  Document. 
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d.  Supp<Mt.  Supp<Mt  includes  any  and  all  services,  data,  and  documentation  necessary  to  qualify 
the  component.  The  level  of  support  is  agreed  as  not  less  than  XX  hours  of  engineering  services 
(specifically  skill  category,  such  as  "senior  software  engineer")  during  the  component  submission 
(»*  resubmission  and  qualification  periods  contemplated  by  paragraphs  4  and  S  of  this  agreement. 

e.  Section  Titles.  Titles  or  captions  in  this  agreement  are  for  reference  purposes  only  and  are 
not  meant  to  be  used  to  define,  limit  or  describe  the  scope  mr  intent  of  this  agreement. 

4.  ComponentCs)  Submission,  Evaluation  and  Qualification  Requirements 

a.  Agency  Q  agrees  to  comply  with  the  compoi^nt  submission  requirements  of  the  CARDS 
library  as  described  in  the  CARDS  Library  Development  Handbook  (dated  mm/dd/yy)  and 
Component  Submittal  Guidelines.  The  component(s)  will  be  supported  by  sufficient 
documentation  to  allow  independent  evaluation  by  the  CARDS  library.  Sufficient  supporting 
documentation  shall  be  provided  to  allow  subscribers  to  ascertain  components  utility  for  intended 
{q>plications.  Agency  Q  agrees  to  provide,  at  no  cost,  any  additional  support  which  may  be 
necessary  to  evaluate  the  compotK:nt(s)  and  related  documentation. 

b.  Agency  Q  will  provide  a  recommendation  regarding  the  appropriate  component  class  for  the 
submitted  components)  within  the  context  of  the  Library  model.  The  library  retains  the  right  to 
assign  the  ultimate  classification. 

c.  The  library  represents  it  will  consider  all  evaluations  in  accordance  with  the  procedures 
described  in  the  Library  Development  Handbook.  Documentation  results  will  be  in  the  fomat  and 
include  the  content  described.  The  CARDS  Library  Operator  persoimel  performing  evaluation 
and  qualification  are  knowledgeable  in  the  component(s)  class(es)  involved. 

d.  While  the  CARDS  Library  Operator  retains  the  absolute  right  to  ultimately  determine  whether 
a  component  is  suitable  for,  accepted,  and  integrated  into  the  library  model,  the  supplier  and  its 
sponsOT  will  be  provided  an  oppcHtunity  to  comment  on  the  evaluation  and  qualification  results. 
The  conunent  period  will  be  for  30  days,  (the  library  needs  to  specify  time  limit)  and  occur 
pricH-  to  q>proving  or  dis^)proving  the  component(s)  for  qualification  and  acceptance  into  the 
library.  The  Library  is  under  no  obligation  to  change  its  evaluation  and  qualification  results 
after  review  and  consideration  of  the  supplier’s  or  the  sponsor’s  comments.  Those  components 
accepted  into  the  library  will  include  the  Library,  supplier,  and  sponsor  comments  as  well  as 
any  submitted  documentation  necessary  to  adequately  describe  the  component(s).  Components, 
evaluation  results,  comments  and  supptxting  documentation  (for  all  accepted  components)  will  be 
available  on-line  to  all  authmized  library  Subscribers.  Any  future  objection  to  the  dissemination 
of  component  evaluation  results  will  be  cause  fcr  terminating  this  agreement  and  removing  the 
componenKs)  from  the  library  (Note:  It  has  been  recommended  that  the  Sbrary  obtain  supplier 
comments  when  feasible  and  to  make  them  available  to  the  account  holders  [1]  [2].  However, 
the  Ubrary  needs  to  determine  the  associated  procedures  in  doing  so.  This  includes  setting 
a  time  limit  and  making  these  comments  available  on-line  to  users.  In  addition,  the  library 
may  want  to  offer  a  reconsideration  after  some  period  to  consider  additional  information,  or, 
experience  with  the  component;  and,  maybe  withdraw  earlier  comments  or  annotate  with  new 
comments.). 
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5.  Component  Resubmission,  Evaluation,  and  Qualification 

a.  Resubmission  of  Previously  Rejected  Components.  Components  not  accepted  after  fomal 
evaluation  and  qualification  testing  must  be  formally  resubmitted  if  the  agency  wishes  to  have 
the  component  reconsidered.  The  agency  will  include  identification  of  the  prior  submission(s) 
and  all  documentation  relating  to  the  earlier  disapproval(s).  The  resubmission  documentation 
will  include  not  only  that  required  for  new  component  submission  but  also  identification  of  any 
changes  made  to  the  component(s)  since  the  last  submission  and  an  analysis  of  why  the  agency 
believes  the  basis  for  lack  of  previous  acceptance  has  been  removed.  The  analysis  will  include 
an  item  by  item  accounting  of  the  Library’s  previous  findings. 

b.  Component  Upgrades.  Component  upgrades  are  considered  new  components.  These 
will  follow  the  submission  requirements  for  new  components  as  a  prerequisite  for  consideration 
by  the  Library  for  evaluation  and  qualification.  Tlie  agency  will  include  identification  of  the 
prior  submission(s),  and  all  documentation  relating  to  prior  dispositions  of  the  component.  The 
submission  package  will  include  a  summary  identifying  the  component(s)  modifications;  the 
purpose  of  the  modifications;  and,  any  agency  perceived  impact  on  prior  Library  evaluation  and 
qualification  findings. 

c.  Resubmission  Limits.  The  library  reserves  the  right  to  limit  resubmissions  or  upgrades  to 
a  reasonable  number  within  any  period  of  time.  The  determination  of  ’reasonable’  is  at  the  sole 
discretion  of  the  library. 

(Note:  It  was  recommended  that  the  Ubrary  determine  the  policy  and  procedures  for  suppUers 
to  re-submit  components.  This  should  include  the  definition  of  **updgrades'*  and  limits  on 
re-submission.  See  [1]  and  [2].) 

6.  Component  Baselines 

The  library  model  will  maintain  only  the  latest  iq)proved  version  of  the  component  and  supporting 
dociunentation  currently  in  CARDS  possession.  CARDS  will  maintain  older  versions  in  its 
possession  off-line  and  will  provide  an  off-line  retrieval  process.  (Note:  A  component  version 
policy  needs  to  be  addressed  by  the  library). 

7.  Ownership,  Rights  and  Limitations 

The  agency  certifies  the  component  and  supporting  documentation  are,  in  fact,  in  the  public 
domain. 

8.  Fees 

The  library  may  in  the  future  charge  fees  for  subscribers  accessing  components  within  the  Library 
model.  The  agency  recognizes  and  agrees  these  fees  are  Library  compensation  and  waives  any 
claim  to  the  fees  collected.  (Note:  The  Library  needs  to  make  a  decision  on  this  issue.) 

9.  Subscriber  Access  Rules  for  Component  Examination  and  Extraction 

a.  The  Library  requires  potential  users  to  complete  the  CARDS  Library  Account  Holder 
Registration  Fmm,  which  indicates  the  account  holder’s  roles  and  responsibilities,  prior  to 
becoming  an  authorized  subscriber  and  gaiiung  access  to  the  CARDS  Library.  The  agency 
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certifies  it  has  examined  this  form  and  accepts  the  adequacy  of  the  protection  afforded  by  user 
execution. 

b.  Subscribers  include  not  only  CARDS  library  account  holders  but  also  those  from  ASSET  and 
DSRS.  The  agency  recognizes  and  agrees  all  subscribers  have  access  to  the  component,  consis¬ 
tent  with  the  terms  of  this  agreement 

10.  Feedbadt  (where  desired) 

The  library  will  provide  subscriber  feedback,  as  it  may  be  obtained,  to  the  supplier  upon 
request,  but  not  more  firequently  than  semi-annually  (Note:  The  Ubrary  needs  to  determine 
the  appropriate  dmeframe)..  The  library  will  not  edit  or  comment  on  the  feedback  in  any  way, 
no*  be  responsible  for  its  dissemination  (authmized  or  unauthorized).  Feedback  may  be  provided 
by  all  Tri-  Lateral  interoperability  subscribers  accessing  the  component  The  records  will  include 
identity  of  subscribers  which  access  the  supplier  component(s).  (Note:  It  was  recommended 
that  the  Sbraryfidetermine  the  poUey  and  procedures  for  requiring  feedback  from  users  on 
supplier  components.  See  [1]  and  PJ.) 

11.  Promotion  and  Advertising 

a.  Once  a  component  is  accepted  into  the  library  model,  the  agency  may  promote  this  fact  and 
its  access  (within  the  scq)e  of  the  library)  without  further  notice  to  the  library.  All  supplier 
promotion  and  distribution  of  materials  must  cease  as  of  the  date  of  expiration  os  termination  of 
the  agreement  The  supplier  is  not  obligated  to  recover  existing,  distributed  materials. 

b.  Acceptance  of  the  component  into  the  library  shall  not  be  constructed  as  an  endorsement. 
Acceptance  connotes  the  component  has  met  the  criteria  for  the  t^plicable  class  and  may  be 
considered  for  use  by  a  subscriber  within  that  class.  All  promotional  material  shall  clearly  exhibit 
a  legend  to  this  effect 

12.  Termination 

This  agreement  may  be  terminated  by  either  party  for  any  reason  by  furnishing  a  notice  in  writing 
by  certified  mail  or  hand  carried.  This  notice  will  be  effective  30  days  after  receipt.  This 
agreement  may  also  be  terminated  by  either  party  for  failure  to  comply  with  any  of  the  material 
requiremmits  of  this  agreement  Termination  will  not  affect  previously  authorized  component 
use  by  any  subscriber.  Termination  will  result  in  removal  of  the  component  from  the  library. 
The  library  will  retain  qualification  results,  supplin'  comments,  and  submitted  documentation  for 
any  component  removed,  and  reserves  the  right  to  allow  subscriber  access  to  this  data.  (Note: 
A  termination  policy  needs  to  be  addressed  by  the  library.) 

13.  Points  of  Contact 

Each  party  shall  annually  provide  notice  to  the  other  of  its  principal  point  of  contact  for  the 
actitms  and  responsibilities  undn  this  agreement,  including  modifications  to  this  agreement 

14.  Modifications  to  the  Agreement 

Modifications  to  this  agreement  shall  be  accomplished  whenever  a  change  in  library  (^>erations, 
or  other  conditions  affecting  the  substance  of  the  agreement  occur,  subject  to  mutual  agreement 
of  the  parties. 
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15.  Signature  Authority 

The  parties  executing  this  agreement  certify  they  are  authorized  by,  and  have  the  full  authcxity 
of  their  respective  (Xganizations  to  commit  to  its  terms  and  conditions  and  bind  the  parties  to  its 
fulfillment 

EXECUTED  THE _ DAY  OF _ ,  199_,  BY 

THE  LIBRARY _ _ 

THE  AGENCY _ 
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423  Contractor  Supplies  Government  Funded  Component 

AGREEMENT  FOR  ACCEPTANCE  OF  COMPANY  Y’S  GOVERNMENT  SPONSORED 
PRODUCT  COMPONENT  INTO  THE  CARDS  LIBRARY 

(Note:  This  covers  both  government  directly  submitted  components  as  well  as  contractor 
submitted  components  under  government  sponsorship.  Remember,  there  wUi  be  situations 
where  the  submitted  component  includes  restricted  rights  software  belonging  to  the  developer; 
COTS  components,  limited  rights  data  and  perhaps  other  types  of  rights  (e.g..  Copyright)  -  all 
these  must  be  identified  and  expUeUfy  marked.  When  the  supplier  is  submitting  tiie  component 
without  government  sponsorship,  all  references  to  the  "sponsor'*  must  be  deleted,  and,  the 
optional  paragraph  under  7.  Ownership,  must  be  added.) 

This  is  an  agreement  between  Unisys  Government  Systems  (or  whichever  entity  operates  the 
library),  the  Operator  of  the  CARDS  Library  (referred  to  as  the  CARDS  Library  Operator  in  the 
remainder  of  this  agreement),  and  Government  Agency  T  and  Company  Y.  (Note:  add  mailing 
and  paying  addresses  here  and  or  later  in  the  agreement.) 

1.  Purpose  of  the  Agreement 

This  agreement  describes  the  puipose,  terms  and  conditions,  including  responsibilities  of  the 
parties,  for  qualifying,  accepting  and  using  COMPANY  Y’S  SOFTWARE  PRODUCT  SPONSO 
within  the  CARDS  library  environment.  Tie  parties  agree  the  CARDS  environment  included 
current  and  future  library  interc^perability  relationships  where  the  product  SPONSO  (referred  to 
as  "component"  in  the  balance  of  this  agreement)  may  be  accessed  by  libraries  other  than  CARDS 
and/or  their  authorized  users  which  have  agreed  to  comply  with  CARDS  use  provisions  and  any 
conditions  for  use  clearly  represented  for  the  component  (Note:  This  indicates  components  that 
are  accessed  by  ASSET  and  DSRS  via  the  interoperabiltty  index.).  The  parties  recognize  and 
agree  the  component  SPONSO  has  been  developed  under  (agency  name)  contract  XYZ-94-S555 
and  is  included  in  the  CARDS  Library  with  the  ownership  rights  certified  by  Company  Y  and 
its  sponsw,  the  (Agency  Name).  The  specific  rights  associated  with  the  product  SPONSO  are 
described  in  an  attachment  to  this  agreement 

2.  Term  of  Agreement 

This  agreement  is  effective  (month/day/year)  and  shall  remain  in  effect  through  (month/day/year), 
unless  terminated  (see  12  below)  or  superseded  by  a  party  or  mutual  agreement 

3.  Definitions 

a.  Commercial'Off-the-shelf  (COTS)  Components  and  Documentation.  COTS  items  are  those 
regularly  used  in  the  course  of  normal  business  qierations  for  other  than  government  purposes. 
These  have  been  sold  or  licensed  to  the  general  public;  or,  have  not  been  sold  or  licensed, 
but  have  been  offered  for  sale  or  license  to  the  general  public;  are  not  yet  available  in  the 
commercial  marketplace,  but  will  be  within  the  term  of  this  agreement  COTS  components  and 
documentation  have  been  develq)ed  at  private  expense,  (h*,  otherwise  determined  to  be  private. 

b.  Government-off-the-shelf  (GOTS)  Components  and  Documentation.  GOTS  items  are 
those  which  have  been  furnished  and  accepted  under  a  federal  government  contract  GOTS 
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components  and  documentation  have  been  developed  at  government  expense;  a-,  have  otherwise 
been  provided  to  the  government  with  specific  license  or  assignment  rights. 

c.  Library  Model.  As  used  in  this  agreement,  library  model  is  the  representation  of  the  CARDS 
library  environment  as  described  in  the  CARDS  Library  Model  Document. 

d.  Support.  Support  includes  any  and  all  services,  data,  and  documentation  necessary  to  qualify 
the  component.  The  level  of  support  is  agreed  as  not  less  than  XX  hours  of  engineering  services 
(specifically  skill  categ(»y,  such  as  ’senior  software  engineer)  during  the  component  submission 
or  resubmission  and  qualification  periods  contemplated  by  paragrtqphs  4  and  S  of  this  agreement 

e.  Section  Titles.  Titles  or  captions  in  this  agreement  are  for  reference  purposes  only  and  are 
not  meant  to  be  used  to  define,  limit  or  describe  the  scope  or  intent  of  this  agreement 

4.  Component(s)  Submission,  Evaluation  and  Qualification  Requirements 

a.  Company  Y  and  its  sponsor  agree  to  comply  with  the  component  submission  requirements 
of  the  CARDS  library  as  described  in  the  CARDS  Library  Development  Handbook  (dated 
nun/dd/yy).  The  component(s)  will  be  supported  by  sufficient  documentation  to  allow 
independent  evaluation  by  the  CARDS  library.  Company  Y  and  its  sponsor  agree  to  provide,  at 
no  cost,  any  additional  support,  as  defined  in  paragraph  3.d  above,  which  may  be  necessary  to 
evaluate  the  component(s)  and  related  documentation. 

b.  Company  Y  and  its  sponsor  will  provide  a  recommendation  regarding  the  t^jpropriate 
component  class  for  the  submitted  component(s)  within  the  context  of  the  Library  model.  The 
library  retains  the  right  to  assign  the  ultimate  classification. 

c.  The  library  represents  it  will  consider  all  evaluations  in  accordance  with  the  procedures 
described  in  the  Library  Development  Handbook.  Documentation  results  will  be  in  the  f(xmat  and 
include  the  content  described.  The  CARDS  Library  Operator  personnel  performing  evaluation 
and  qualification  are  knowledgeable  in  the  components)  class(es)  involved 

d.  While  the  CARDS  Library  Operator  retains  the  absolute  right  to  ultimately  determine  whether 
a  component  is  suitable  f(x,  accepted,  and  integrated  into  the  library  model,  the  supplier  and  its 
sponsw  will  be  provided  an  opportunity  to  comment  on  the  evaluation  and  qualification  results. 
The  comment  period  will  be  for  30  days,  (ihe  library  needs  to  spec^  time  Umit)  and  occur 
priOT  to  approving  or  disi^roving  the  component(s)  for  qualification  and  acceptance  into  the 
library.  The  Library  is  under  no  obligation  to  change  its  evaluation  and  qualification  results 
after  review  and  consideration  of  the  supplier’s  or  the  sponsor’s  comments.  Those  components 
accepted  into  the  library  will  include  the  Library,  supplier,  and  sponsor  comments  as  well  as 
any  submitted  documentation  necessary  to  adequately  describe  the  component(s).  Components, 
evaluation  results,  comments  and  supporting  documentation  (for  accepted  components)  will  be 
available  on-line  to  all  autiuxized  Library  Subsaibers.  Any  future  objection  to  the  dissemination 
of  component  evaluation  results  will  be  cause  for  terminating  this  agreement  and  removing  the 
component(s)  from  the  library.  (Note:  It  has  been  recommended  that  the  library  obtain  supplier 
comments  when  feasible  and  to  make  them  avaUable  to  the  account  holders  [I]  [2].  However, 
the  library  needs  to  determine  the  associaied  procedures  in  doing  so.  This  includes  setting 
a  time  limit  and  making  these  comments  available  on-line  to  users.  In  addition,  the  library 
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may  want  to  offer  a  reconsideration  after  some  period  to  consider  additional  information,  or, 
experience  with  the  component;  and,  maybe  withdraw  earlier  comments  or  annotate  with  new 
comments.) 

5.  Component  Resubmission,  Evaluation,  and  Qualification 

a.  Resubmission  of  Previously  Rejected  Components.  Components  not  accepted  after  fcnnal 
evaluation  and  qualification  testing  must  be  formally  resubmitted  if  the  supplier  and/or  sponsw 
wish  to  have  the  component  reconsidered  The  supplier  or  sponsm*  will  include  identification 
of  the  prior  submission(s)  and  all  documentation  relating  to  the  earlier  disq)proval(s).  The 
resubmission  documentation  will  include  not  only  that  required  for  new  component  submission 
but  also  identification  of  any  changes  made  to  the  component(s)  since  the  last  submission  and  an 
analysis  of  why  the  agency  believes  the  basis  for  lack  of  previous  acceptance  has  been  removed. 
The  analysis  will  include  an  item  by  item  accounting  of  the  Library’s  previous  findings. 

b.  Component  Upgrades:  Component  upgrades  are  considered  new  components.  These  will 
follow  the  submission  requirements  for  new  components  as  a  prerequisite  for  consideration  by 
the  Library  for  evaluation  and  qualification.  The  supplier  or  sponsor  will  include  identification 
of  the  prior  submission(s),  and  all  documentation  relating  to  prior  dispositions  of  the  component. 
The  submission  package  will  include  a  summary  identifying  the  component(s)  modifications;  the 
purpose  of  the  modifications;  and,  any  supplier  perceived  impact  on  pricM*  Library  evaluation  and 
qualification  findings. 

c.  Resubmission  limits;  The  library  reserves  the  right  to  limit  resubmissions  or  upgrades  to  a 
reasonable  number  within  any  period  of  time.  The  determination  of  ’reasonable’  is  at  the  sole 
discretion  of  the  Ulx-ary. 

(Note:  It  was  recommended  that  the  library  determine  the  policy  and  procedures  for  suppliers 
to  re-submit  components.  This  should  include  the  definition  of  **updgrades**  and  limits  on 
re-submission.  See  [1]  and  [2].) 

6.  Componoit  Basdines 

The  library  model  will  maintain  only  the  latest  approved  version  of  the  component  and  supporting 
documentation  currently  in  CARDS  prossession.  CARDS  will  maintain  older  versions  in  its 
possession  off-line  and  will  provide  an  off-line  retrieval  process.  (Note:  A  component  version 
poSey  needs  to  be  addressed  by  the  library). 

7.  Ownership  Disclosure,  Rights  and  Limitations 

a.  By  executing  this  agreement,  the  supplier  and  its  sponsor  certify  they  have  accurately 
rquresented  the  component(s)  with  respect  to  existing  domestic  and/tx  international  proprietary; 
copyright;  patent;  trademark;  federal  government  unlimited,  limited,  restricted  and/(x  government 
puipose  rights,  specifically  including  any  rights  or  limitations  regarding  Foreign  Military  Sales 
or  federally  sponsored  International  agreements,  or  in  the  case  of  restricted  rights,  specifically 
stating  any  additional  rights  granted  over  the  minimum  rights.  The  supplier  and  its  sponscx 
will  e]q>ressly  describe  any  limitations  on  reuse  of  the  component(s)  "as  is";  for  the  purpose 
of  creating  derivative  wcxks;  including  the  right  to  modify  the  components).  Any  special 
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limitationa/granting  of  rights  such  as  use  by  educational  institutions;  direct  sales  to  foreign 
governments  or  direct  foreign  commercial  sales  shall  be  expressly  idendiied. 

b.  The  library  places  full  reliance  on  the  representations  addressed  in  paragrf^h  7.a.,  and  is  not 
responsible  for  any  imauthorized  use  resulting  from  improper  or  erroneous  certifications  or  lack 
of  markings. 

c.  All  authcuized  users  will  be  notified  of  all  disclosures  regarding  ownership,  prim-  to  accessing 
a  component.  The  supplier  and  its  sponsor  agree  to  relieve  the  library  from  responsibility  for 
impropo-  use  by  any  authorized  subscriber. 

d.  OPTIONAL.  The  supplier  certifies  it  has  obtained  all  necessary  releases,  licenses,  or  other 
Impropriate  permissions  from  its  government  agency,  which  funded  the  component  development, 
to  place  the  component  in  the  Library  without  fmrnal,  joint  sponsor  execution  of  this  agreement. 

8.  Fees 

The  library  may,  in  the  future,  charge  fees  for  subscribers  accessing  components  within  the 
Library  model.  The  supplier  and  its  sponsor  recognize  and  agree  these  fees  are  Library 
compensation  and  waive  any  claim  to  the  fees  collected.  (The  Library  needs  to  make  a  decision 
on  this  issue). 

9.  Subscriber  Access  Rules  for  Component  Examination  and  Extraction 

a.  The  Library  requires  potential  users  to  complete  the  CARDS  Library  Account  Holder 
Registration  Form,  which  indicates  the  account  holder’s  roles  and  responsibilities  prior  to 
becoming  an  authorized  subscriber  and  gaining  access  to  the  CARDS  Library.  The  supplier 
and  its  sponsor  agree  they  have  examined  this  form  and  accept  the  adequacy  of  the  protection 
afforded  by  user  execution. 

b.  Subscribers  include  not  only  CARDS  library  account  holders  but  also  those  from  ASSET 
and  DSRS.  The  supplier  and  its  sponscx  recognize  and  agree  all  subscribers  have  access  to  the 
component,  consistent  with  the  terms  of  this  agreement(A^o<e:  A  suppUer  may  want  to  restrict 
its  Ucense  to  Just  the  CARDS  site  {single  or  mulH-user}  versus  multi-site,  multi-user  licenses 
for  the  actual  component  itself.  This  must  be  discussed  and  then  limited  if  full  Tri-Lateral 
Interoperability  access  is  not  desired  by  the  supplier). 

c.  In  the  event  the  supplier  has  commercial  rights  to  the  components),  it  recognizes  the 
Library  does  not  currently  provide  a  cim^^^^  subscriber  extraction  of  commercial/privately 
developed  components.  The  library  will  identify  "pointers"  for  subscribers  to  the  supplier’s 
source  of  distribution;  any  federal  distribution  mechanisms  (i.e.,  GSA  (x  similar  contract 
vehicles);  (x  any  third  party  distributors  if  these  are  provided  by  the  component  supplier.  In  the 
event  the  library  elects  to  become  a  distributor,  the  supplier  agrees  to  support  this  library  role 
and  negotiate  an  equitable  fee  for  library  services  in  distributing  the  product. 

d.  The  library  will  incmpm-ate  into  its  model  any  accq>ted,  government  controlled  component(s). 
Any  fee  to  which  the  sponscx  is  entitled  from  the  subscriber  is  the  responsibility  of  the  sponsor  to 
collect.  The  sponsor’s  ownership  notifications  under  paragr^)h  7  of  this  agreement  shall  include 
a  notice  regarding  whether  subsaiber  use  is  subject  to  payment  of  a  fee.  The  notice  regarding 
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whether  subscriber  use  is  subject  to  payment  of  a  fee.  The  notice  will  clearly  state  differences 
03  fee  liability  with  respect  to  subsaiber  use  (e.g.,  for  another  federal  organization  within  the 
same  agency;  other  federal  agency;  state  or  local  agencies;  foreign  governments;  contractors 
perfcHming  under  contract  for  the  same  agency;  or  different  agency  contracts;  foreign  country 
contractOTs  perfcHming  under  the  same  agency  or  other  agency  contracts;  or  any  other  relationship 
which  may  have  a  bearing  on  whether  a  fee  is  charges  or  the  amount  of  such  fee). 

10.  Feedback  (where  desired) 

The  library  will  provide  subscriber  feedback,  as  it  may  be  obtained,  to  the  supplier  upon 
request,  but  not  more  frequently  than  semi-annually  (Note:  The  Ubrary  needs  to  determine 
the  appropriate  timeframe).  The  library  will  not  edit  or  comment  on  the  feedback  in  any  way, 
nm*  be  responsible  for  its  dissemination  (authorized  or  unauthorized).  Feedback  may  be  provided 
by  all  Tri-  Lateral  interoperability  subscribers  accessing  the  component.  The  records  will  include 
identity  of  subscribers  which  access  the  supplier  component(s).  (Note:  It  was  recommended 
that  the  Ubrary  determine  the  policy  and  procedures  for  requiring  feedback  from  users  on 
supplier  components.  See  [1]  and  [2].) 

11.  Promotion  and  Advertising 

a.  Once  a  component  is  accepted  into  the  library  model,  the  supplier  or  its  sponsor  may  promote 
this  fact  and  its  access  (within  the  scope  of  the  library)  without  further  notice  to  the  library. 
All  supplier  promotion  and  distribution  of  materials  must  cease  as  of  the  date  of  expiration 
or  termination  of  the  agreement.  The  supplier  is  not  obligated  to  recover  existing,  distributed 
materials. 

b.  Acceptance  of  the  component  into  the  library  shall  not  be  constructed  as  an  endorsement. 
Acceptance  connotes  the  component  has  met  the  criteria  for  the  iq>plicable  class  and  may  be 
considered  for  use  by  a  subscriber  within  that  class.  All  promotional  material  shall  clearly  exhibit 
a  legend  to  this  effect. 

12.  Termination 

a.  This  agreement  may  be  terminated  by  either  party  for  any  reason  by  furnishing  a  notice  in 
writing  by  certified  mail  or  hand  carried.  This  notice  will  be  effective  30  days  after  receipt.  This 
agreement  may  also  be  terminated  by  either  party  for  failure  to  comply  with  any  of  the  material 
requirements  of  this  agreement  Termination  will  not  affect  previously  authorized  component 
use  by  any  subscriber.  Termination  will  result  in  removal  of  the  component  from  the  library. 
The  library  will  retain  qualification  results,  supplier  comments,  and  submitted  dociunentation  fa* 
any  component  removed,  and  reserves  the  right  to  allow  subscriber  access  to  this  data. 

b.  This  agreement  may  also  be  terminated  at  the  request  of  the  sponsor.  (Agency  Name)  without 
any  recourse  by  Company  Y;  except  for  resubmission  (see  paragrtqjh  5)  under  Company  Y 
private  spons(»ship,  if  consistent  with  paragraph  7  entitled  Ownership. 

(Note:  A  termination  policy  needs  to  be  addressed  by  the  Ubrary.) 

13.  Assignment  of  Agreement 
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Assignment  will  be  automatic  unless  this  agreement  is  first  terminated  in  writing  by  either  party. 
The  parties  agree  to  automatically  assign  this  agreement  to  success^  interests  when:  (1)  the 
current  operator  of  the  library  sells  <x  transfers  its  rights  and  interests  to  the  contract  for  library 
operation;  (2)  the  supplier  is  bought  out  or  sells  the  rights  to  its  component(s)  to  some  other 
entity;  (3)  the  sponsor  transfers  control  of  the  component  to  another  agency.  The  library  reserves 
the  right  to  terminate  the  agreement  with  any  successor  party. 

14.  Indemnification 

a.  The  supplier  indmnnifies  the  library  against  any  user  misrepresentations;  illegal,  or,  otherwise 
im^ipropriate  uses  of  the  components  and  supporting  documentation  covered  by  this  agreement. 
The  supplier  recognizes  and  accepts  that  the  library  has  executed  user  agreements  in  good 
faith  and  exercised  reasonable  diligence  in  it  procedures  to  avoid  improper  or  prohibited  use  of 
components  and  documentation.  (Note:  this  clause  implies  to  Company  X  supplier  only.  Delete 
this  clause  when  the  agreement  is  with  the  Government  sponsor.) 

b.  The  library  places  full  reliance  on  the  representations  addressed  in  paragraph  7. a.  and  is  not 
responsible  for  any  vmauthcrized  use  resulting  from  improper  or  erroneous  certifications  or  lack 
of  markings. 

c.  CARDS  is  part  of  the  interoperability  library  system  (currently  consisting  of  CARDS,  ASSET, 
and  DSRS).  The  supplier  and  the  sponsor  have  reviewed  the  Memorandum  Of  Understanding 
for  Tri-  Lateral  Interoperability  and  agree  it  is  sufficient  to  protect  their  rights  and  interests. 

(Note:  UabiUty  for  gross  negUgence  and  intentional  violation  of  license  agreements  by  the 
Ubrary  or  its  staff  is  not  protected  by  this  provision.) 

15.  Governing  Statntes 

This  agreement  is  subject  to  the  laws  of  the  state  of  YY  (add  the  state  in  which  Unisys 
is  incoiporated.  If  an  entity  other  than  Unisys  operates  the  library,  enter  the  appropriate 
incmporating  state)  however,  the  parties  agree  to  submit  to  binding  arbitration  to  resolve  any 
disputes.  (Nide:  this  clause  appUes  to  Company  X  supplier  only.  Delete  this  clause  when  the 
agreement  is  with  the  Government  sponsor.) 

16.  Points  of  Contact 

Each  party  shall  annually  provide  notice  to  the  other  of  its  principal  point  of  contact  for  the 
actions  and  responsibilities  under  this  agreement,  including  modifications  to  this  agreement. 
Note:  The  library  needs  to  make  a  decision  on  policies  and  procedures  regarding  points  of 
contact  data. 

17.  Modifications  to  the  Agreement 

Modifications  to  this  agreement  shall  be  accomplished  whenever  a  change  in  library  operations. 
or  other  conditions  affecting  the  substance  of  the  agreement  occur,  subject  to  mutual  agreement 
of  the  parties. 
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18.  Signature  Authority 

The  parties  executing  this  agreement  certify  they  are  authorized  by,  and  have  the  full  authority 
of  their  respective  wganizations  to  commit  to  its  terms  and  conditions  and  bind  the  parties  to  its 
fulfillment. 

EXECUTED  THE _ DAY  OF _ ,  199_.  BY 

THE  LIBRARY _ 

THE  SUPPLIER _ 

THE  SPONSOR _ 
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5  EXTRACTING  COMPONENTS 
5.1  Implementing  Account  Registrations 

Since  the  library  allows  only  Government  agencies  and  their  contractors  to  obtain  an  account, 
the  library  must  determine  whether  or  not  a  prospective  account  holder  meets  the  appropriate 
requirements.  However,  user  responsibilities  will  be  the  same  no  matter  if  the  user  is  a 
Government  employee  or  a  contractor.  Users  are  concerned  with  issues  regarding;  component 
evaluation,  component  withdrawal,  security  and  maintenance.  How  each  of  these  issues  impact 
users  are  discussed  below. 

Users  rely  upon  the  evaluation  criteria  and  results  so  that  they  can  make  a  sound  technical  and 
business  decision  of  whether  or  not  to  re-use  a  particular  component  and  to  determine  whether 
or  not  the  component  fits  into  their  implication.  In  fact  some  users  may  want  to  know  what 
the  evaluation  aiteria  are,  as  well  as  what  components  are  in  the  library,  before  they  make  a 
decision  to  obtain  an  account.  Thus  the  library  must  be  careful  to  provide  up  to  date  evaluation 
criteria  and  acceptance  procedures  to  both  the  supplier  and  users. 

Although  policies  and  procedures  regarding  component  access,  withdrawal,  and  reuse  are  aimed 
toward  users  of  the  library,  and  if  applicable,  users  of  interoperating  libraries,  they  also  are 
governed  by  information  and  restrictions  supplied  by  the  original  developer.  Thus,  the  original 
supplier  also  has  an  interest  in  these  procedures. 

Component  withdrawal  procedures  should  include:  information  the  library  will  supply  to  the 
users,  how  that  information  is  relayed  (e.g.,  on-line,  e-mail,  letter),  what  the  user  should  expect 
from  the  library  (i.e.,  services),  and  what  the  library  expects  from  the  user  (i.e.,  rules  the  user 
is  expected  to  abide  by).  The  library  is  responsible  to  ensure  that  the  user  is  made  aware  of 
the  intellectual  property  rights  and  associated  distribution  and  use  limitationsA'estrictions  of  a 
component.  This  also  includes  data  that  may  or  may  not  be  extracted  with  a  component,  such  as 
documentation,  product  abstracts  and  descriptions,  purchasing  and  product  marketing  information 
and  component  evaluation  results. 

These  procedures  should  be  easily  understood  and  easily  accessible.  Since  the  library  has  a 
responsibility  to  the  supplier  to  relay  this  information,  the  library  has  an  additional  responsibility 
to  make  sure  the  information  is  up  to  date  and  made  readily  available  to  users.  It  is  probably 
best  to  keep  the  copyright,  use  and  distribution  limitation  attached  to  the  component  on-line, 
so  when  a  user  accesses  the  component,  they  automatically  see  this  information.  In  addition, 
the  library  may  want  to  go  one  step  further  and  incorporate  security  measures  into  the  library 
mechanism. 

The  library  should  also  tell  the  users  what  the  library  expects  from  them,  before  the  user  obtains 
an  account.  This  way,  the  user  has  the  iq)propriate  information  to  make  an  informed  decision 
bef(H%  they  make  a  commitment  to  the  library.  This  will  protect  the  library  from  the  user 
charging  that  they  were  not  aware  of  the  rules  or  were  mislead. 

Another  protection  for  the  library  is  to  have  the  user  sign  a  statement  agreeing  to  abide  by 
and  follow  the  library’s  procedures  for  access  and  use  of  components.  Another  protection  is  to 
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have  the  user  agree  to  accept  the  component  "as  is"  with  any  warranty  provided  by  the  original 
supplier.  The  library  could  have  the  user  release  the  library  from  any  liability,  but  the  library 
must  also  be  able  to  provide  the  user  with  the  necessary  information  they  need  to  determine 
whether  or  not  to  use  the  component.  The  library  should  also  be  piudent  when  asking  for  a 
release  of  liability  in  agreements.  The  library  does  not  want  the  release  of  liability  to  be  so 
prominent  that  the  users  infer  that  the  library  is  incompetent. 

The  library  may  want  to  request  feedback  on  component  usage  to  assist  them  in  maintaining  the 
domain  model,  library  and  components. 

In  turn,  the  user  has  expectations  of  the  library.  User’s  want  to  know  that  the  library  is 
authorized  to  distribute  the  component  and  that  the  library  accurately  represents  the  component 
with  respect  to  capabilities,  documentation,  and  currency  of  component  version 

Library  users  should  be  made  aware  of  the  library’s  security  policies  and  procedures  that  govern 
their  use  of  the  library. 

The  user  would  also  want  to  know  the  library’s  policy  for  component  maintenance  before  they 
do  business  with  the  library. 
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Account  Registration  Form 

The  following  Account  Registration  Form  includes  instructions  for  the  prospective  account  holder 
to  fill  out  the  form,  the  roles  and  responsibilities  that  they  will  be  required  to  follow  once  an 
account  is  granted,  and  a  questionnaire  requesting  information  on  their  (H^ganization,  computer 
and  terminal,  and  Government  contracts.  It  also  requires  the  account  holder  to  sign,  as  well 
as  a  Government  Program  Manager,  Task  Coordinator  or  Project  Lead.  There  are  some  topics 
addressed  here  that  require  policy  decisions  by  the  CARDS  Library;  these  are  indicated  in 
italicized-bold  font  (For  recommended  policy  changes,  see  [1]  and  [2]). 

CENTRAL  ARCHIVE  FOR  REUSABLE  DEFENSE  SOFTWARE  (CARDS)  LIBRARY 
ACCOUNT  REGISTRATION  FORM  (CLARF) 

PURPOSE 

This  form  is  used  to  request  an  account  with  the  CARDS  Command  Center  Library.  Instructions 
follow. 

INSTRUCTIONS 

1.  Read  the  Roles  and  Responsibilities  sections. 

2.  Complete  all  items  on  this  fom.  All  of  the  following  requested  information  MUST 
BE  completed  before  an  account  wiU  be  activated: 

-  Registration  InfcHnmation:  Organizational  Information,  Computer/Terminal 
Information,  Government  Contract  Information 

'  Organization  Authorization 

-  Unique  Identification  information 

3.  Please  print  or  type. 

4.  Sign  and  date  form. 

5.  Obtain  authorized  signature  from  Government  Program  Manager,  Task  Coordinator 
or  Project  Lead  and  date. 

6.  Return  the  completed  form  by  mailing  to: 

CARDS  Command  Center  Library 
ATTN:  CARDS  User  Support  -  CLARF 
1401  Country  Club  Road,  Suite  201 
Fairmont,  WV  26554 

ROLES  AND  RESPONSIBILITIES 

1.  The  CARDS  Library 
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The  Library  Account  Holder  understands  and  agrees  that: 

A.  Components  are  provided  "as  is"  by  the  supplier  and  all  accompanying  information 
is  certified  by  the  supplier/developer  of  the  component.  The  accuracy  of  this  nfcM*- 
mation  is  limited  to  the  extent  of  the  suppliers  submittal.  Thus,  CARDS  makes  no 
further  warranty  as  to  the  accuracy,  fitness,  reliability,  or  safety  of  the  reusable 
components  available  through  the  library. 

2.  Terms  of  a  CARDS  Account 

The  Library  Account  Holder  understands  and  agrees  to: 

A.  Account  registration  is  effective  after  processing  is  complete  by  the  library  (approxi¬ 
mately  two  weeks  after  receipt  by  the  library).  Account  registration  may  be 
terminated  for  failure  to  comply  with  any  of  the  material  requirements  indicated  un¬ 
der  the  Roles  and  Responsibilities  section.  CARDS  reserves  the  right  to  revoke 
access,  privileges,  (x  services  without  notice. 

B.  Use  CARDS  Library  Account  ftx  intended  purpose  as  stated  below  under  the 
"contract  Information"  section. 

Library  accounts  are  distributed  to  aid  in  the  process  of  domain-specific  reuse. 
Use  of  the  CARDS  Library  System  resources  for  research,  training,  prototyping, 
or  building  systems  is  ^prqpriate  usage.  Game  playing,  large  amounts  of  e-mail, 
and  gambling  pools  are  examples  of  inappropriate  usage. 

C.  This  agreement  is  executed  by  the  CARDS  Library  and  the  Accoimt  Holder. 

D.  Notify  the  CARDS  Hotline  at  hotline@cards.com  or  (8(X))  828-8161  if  any  informa¬ 
tion  reported  in  the  Registration  Information  (Organizational  Information, 

Compute' Terminal  Information  or  Government  Contract  Information)  or  the 
Organizational  Authorization  sections  below  have  changed. 

3.  CARDS’  Computing  Resources 

The  Library  Account  Holder  understands  and  agrees  to: 

A.  Comply  with  all  intellectual  property  rights  and  Government  usage  rights  regarding 
usage,  duplication,  and  distribution.  Not  make  nor  use  illegal  copies  of  copyrighted 
software,  store  such  copies  on  other  library  systems,  or  transmit  them  over  library 
netw<M‘ks. 

Use  of  GOTS  components  is  limited  to  the  express  use  permitted  under  the 
sponsming  Government  contract  under  which  the  component  has  been  developed, 
unless  it  is  develq>ed  and  provided  with  totally  unrestricted  rights. 

Users  can  directly  extract  Public  domain  and  GOTS  components  (if  indicated) 
from  the  library  (Instructions  for  doing  so  are  in  the  CARDS  User’s  Guide). 
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Users  are  not  allowed  to  extract  COTS  components.  The  necessary  purchase 
information  is  provided:  either  point  of  contact  for  a  dealer  or  vendor  m 
infomation  on  available  GSA  listing.  Those  components  that  the  library  owns  a 
site  license  can  be  invoked  by  users  and  are  also  included  in  the  demonstrations 
provided  on-line. 

B.  Use  resources  only  for  authcnized  purposes. 

C.  Be  considerate  in  usage  of  shared  resources.  Refrain  from  monopolizing  systems, 
overloading  networks  with  excessive  data,  or  wasting  computer  time,  connect  time, 
disk  space,  or  other  resources. 

D.  Be  considerate  in  usage  of  network  resources.  Make  large  file  transfer  at  times 
other  than  peak  hours.  If  extremely  large  files  need  to  be  transferred,  contact  the 
CARDS  Hotline  to  make  other  arrangements. 

4.  Password  Secvirity 

The  Library  Accoimt  Holder  imderstands  and  agrees  to: 

A.  Change  your  password  when  you  initially  Ic^-on  to  the  system  (the  first  time  you 
use  your  account).  Do  this  for  both  your  UNIX  and  your  APS  (Andrew  File 
System)  passwtxds  (where  applicable). 

B.  Protect  your  passwrxd  from  unauthorized  use.  You  are  responsible  for  all  activities 
on  your  user  ID. 

C.  Change  your  password  regularly  by  using  the  command  "passwd"  for  the  UNIX  sys¬ 
tem  and  "lq)asswd”  for  the  AFS  system.  (Afirte:  This  clause  must  be  changed  when 
the  security  procedures  on  changing  passwords  is  finalized). 

D.  Not  give  your  password  to  any  other  individual.  If  your  password  is  compromised, 
change  it  inunediately,  and  contact  the  CARDS  Hotline. 

E.  Not  type  your  password  while  someone  is  watching. 

F.  Avoid  passwmds  that  reference  personal  data,  your  friends,  your  pets,  or  your  family 
(names,  birthdates,  etc.). 

G.  Avoid  using  passwcads  that  are  contained  in  the  dictionary,  or  that  are  popular  in 
your  environment  (i.e.,  pencil,  reuse,  library,  CARDS,  etc.). 

H.  Use  passwords  that  have  mixed  lower  and  upper  case  letters,  as  well  as  numbers  or 
other  special  characters  (i.e.,  ASlldc,  kR4DsJ,  hj45d9,  etc.) 
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I.  Not  use  the  same  passwcnxl  for  both  your  UNIX  and  AFS  accounts. 

J.  Not  use  computer  programs  to  decode  passwoxls  or  access  control  information. 

5.  Privacy  of  Othor  CARDS’  Library  Account  Holders 

The  Library  Account  Holder  understands  and  agrees  to: 

A.  Access  only  files  and  data  that  are  your  own,  that  are  publicly  available,  or  to  which 
you  have  been  given  authorized  access. 

B.  Not  use  another  library  Account  Holder’s  user  ID,  password,  or  account. 

C.  Not  to  use  another  library  Account  Holder’s  files  and/or  data  without  permission. 

D.  Not  intentionally  seek  information  about,  obtain  copies  of,  or  modify  files,  tapes, 
passw(»ds,  or  any  type  of  data  or  programs  belonging  to  other  Library  Account 
Holders. 

E.  Not  develop  nor  execute  programs  that  could  harass  other  Library  Account  Holders. 

P.  Allow  the  CARDS  library  to  provide  infcxmadon  to  component  suppliers  regarding 
identity  and  location  of  subscriber’s  accessing  their  components.  (Note:  The  account 
holder  is  offered  a  choice  of  whether  or  not  to  use  this  informadonfor  promotional, 
advertising  or  marketing  information.  Account  holder  information  is  not  currently 
suppUed  to  the  supplier,) 

6.  CARDS’  System  Integrity 

The  Library  Account  Holder  understands  and  agrees  to; 

A.  Not  attempt  to  circumvent  or  subv«t  system  security  measures. 

B.  Not  engage  in  any  activity  that  might  be  harmful  to  systems  or  to  any  information 
straed  thereon,  such  as  creating  or  prt^agafing  viruses,  disrupting  services,  or 
damaging  files. 

C.  Not  attempt  to  alter  or  avoid  accounting  of  computer  services. 

D.  Not  develq>  or  execute  programs  that  could  infiltrate  systems,  damage  or  alter 
software  components,  or  use  any  sovices  for  unauthorized  or  unintended  puiposes. 

E.  Report  security  faults  to  the  CARDS  Hotline.  If  a  flaw  is  discov^-ed,  do  not  ex¬ 
ploit  that  flaw.  Contact  the  CARDS  Hotline  at  hotline@cards.com  or  (800) 
828-8161,  and  explain  the  fault.  Trying  to  expltxe  the  flaw  on  your  own,  testing  it 
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out  to  see  its  Mtent  or  effect,  is  unethical  and  unacceptable  because  the  library 
Staff  has  no  way  to  distinguish  curious  exploution  from  malicious  intention. 

7.  Mail  and/w  Messaging  Services 

The  Library  Account  Holder  undmtands  and  agrees  to: 

A.  Not  use  the  mail  facility  to  harass,  intimidate,  or  otherwise  annoy  any  other  Library 
Account  Holder  (i.e.,  broadcasting  unsolicited  messages,  sending  unwanted  mail, 
etc,). 

B.  Not  send  fraudulent  mail  or  break  into  another  Library  Accoimt  Holder’s  electronic 
mailbox. 

C.  Not  merely  use  the  library  as  a  mailstop.  CARDS  is  a  library  designed  for  promoting 
reuse  in  government,  industry,  and  academia.  The  e-mail  functionality  at  the  Library 
is  not  intended  for  ctHrespondence  otho*  than  that  specifically  related  to  the  Library. 
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REGISTRATION  INFORMATION 

Organizational  Information 

1.  Point  of  Contact 

Name: _ 

Utle/Rank: _ 

Company  Name/Service: _ 

Of  ce  Symbol/Code: _ 

Street  Address: _ 

Qty/Base/Mililaiy  Station: _ 

State: _  Zip  Code: _ 

Country: _ 

Daytime  Phone  Number  (N<m-DSN  Number): _ Ext:. 

Fax  Number: _ 

E-Mail  Address: _ 

2.  What  is  your  primary  business  activity? 

( )  Air  Force  ( )  Marine  Coq}s 

(  )  Anny  (  )  Navy 

OCoastGuard  ()DoD 

()  Other  (NSA,  NASA,  etc.)  Please  specify: _ 

3.  What  is  your  primary  job  fiincticm? 

( )  Data  Processing  ( )  Programming 

()  Executive  SES  ()  Program  Manager 

( )  Maintenance  ( )  Research/Develc^ent 

Figure  5-1  REGISTRATION  INFORMATION  Part  1  of  5 
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( )  Management  ( )  Software  Engineering 

( )  Operations  ( )  Systems  Integration/Design 

( )  Planning  ( )  Test^valnatimi 

( )  Procurement  ( )  Otiier,  please  specify: _ 

4.  Are  you  a  member  of  any  Reuse  special  interest  groups?  (example;  SIGAda,  RIG) 

( )  No  ( )Yes.  please  list: _ 

5.  Have  you  ever  used  a  software  reuse  library? 

( )  No  ( )  Yes,  please  list _ 

6.  Have  you  received  a  copy  of  the  CARDS  Inftxmatioo  Packet? 

()No  ()Yes 

Computer/Terminal  Information 

1.  Please  identify  someone  in  your  organization  that  we  may  contact  for  informaticm  about  your 
system. 

Systems  Admirustrator  Name:. _ _ _ 

Systems  Admirusttattv  Phcme:  _ 

2.  Please  note  the  IP  addresses  and  correspmiding  luunes  for  all  machines  from  which  you  will 
access  the  CARDS  library.  (The  IP  number  is  an  address,  assigned  by  DDN  Network  Infrxmation 
Center,  for  uiuquely  identifying  machines  tm  a  world  wide  networir.) 


IP#; 

IP#: 

IF# 

IP#: 

IP#; 

IP#: 

IP#; 

IP# 

Figure  5-2  REGISTRATION  INFORMATION  Part  2  of  5 
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DP#:  IP#: 

Government  Contract  Information 

1.  Are  You  a  United  States  Gtizen? 

OYes  ()No 

2.  Are  you  a  Government  Employee? 

OYes  ()No 

3.  Are  You  a  Government  Coatractm/Subccmtiactoi? 

OYes  ONo 

4.  Government  Program/Project: 


(If  you  are  working  on  more  than  one  project^[XX>gram.  please  provide  the  most  {q>propriate.) 


5.  Govenunent  Contract  Number: 


6.  Government  Contract  Erq>irBtion 

Date: _ 

7.  Purpose  for  requesting  an  account' 


Figure  5-3  REGISTRATION  INFORMATION  Part  3  of  5 
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8.  Where  did  you  hear  about  CARDS?  (example;  Articles,  conferences,  etc.) 


9.  The  library  will  provide  account  holder  infonnation  to  suppliers  for  feedback  and  tracking 
purposes  only.  Do  you  wish  this  information  to  be  used  for  promotional,  advertising  or  marketing 
infonnation  by  tire  supplier  of  ibt  component? 

OYes  ()No 

Figure  5-4  REGISTRATION  INFORMATION  Part  4  of  5 
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ORGANIZATIONAL  AUTHORIZATION 

Please  include  an  audumzed  signature  from  one  of  die  following:  Government  Program  Manager. 
Tluic  Coordinator,  Project  Lead,  etc. 

Audiorized  by: _ Date: _ 

Please  Print  Name  &.  Title/Rank 


Address: 


Phone:  (  ) 


Signature 


ACCOUNT  HOLDER  AGREEMENT 


I  have  read  the  Roles  and  Responsibilities  Section  of  diis  form  and  understand  and  agree  to  the 
terms,  conditions  and  restrictians  stated  therein.  Hie  User  and  CARDS  agree  that  diese  Roles  and 
Responsibilities  shall  be  governed  by  die  Laws  of  the  United  States  of  America 

Applicantfis  Name: _ Date: _ 

Please  Print 


Signature 


UNIQUE  IDENTinCATION  INFORMATION 

Enter  any  four  keyboard  characters.  This  will  NOT  be  your  password;  but  you  will  need  diis  for 
security  and  validation  purposes. 


Figure  5-5  REGISTRATION  INFORMATION  Part  5  of  5fi 
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6  INTEROPERABILITY  CONSIDERATIONS 

In  order  to  ensure  smooth  operations  between  and  among  CARDS,  the  Asset  Source  fcM*  Software 
Engineering  Technology  (ASSET)  and  the  Defense  Software  Repository  System  (DSRS),  a  tri¬ 
lateral  Memorandum  of  Understanding  (MOU)  is  being  developed  to  document  the  roles  and 
responsibilities  of  each  library.  MOUs  are  an  instrument  that  are  used  between  Government 
agencies  to  outline  what  tasks  each  organization  will  perform  and  how  they  will  be  performed 
imder  certain  circumstances  or  situations.  Although  Memoranda  of  Agreements  (MO A)  are 
more  formal  than  MOUs,  they  too  are  documents  written  for  use  between  two  Government 
agencies.  The  tri-lateral  MOU  is  being  developed  to  fit  into  the  current  interoperability  concept 
of  operations,  but  may  need  to  change  over  the  long  term  to  incorporate  some  long  term  DoD 
plans.  If  the  CARDS  library  interoperates  with  non-Govemment  libraries  in  the  future,  liability- 
related  clauses,  discussed  in  Section  3,  will  need  to  be  added.  An  agreement  would  be  used 
instead  of  an  MOU.  Some  issues  that  should  be  considered  are  discussed  below. 

It  is  not  {^jparent  to  a  user  when  they  view  and  access  a  component  that  has  been  incorporated 
into  the  library  model  from  another  library’s  index.  From  the  user’s  perspective  of  utilizing  a 
domain-specific  library,  this  is  a  good  feature  (i.e.,  seamless  interoperation).  Although  this  is 
currently  working  with  only  three  libraries,  it  would  seem  that  it  could  become  very  tedious  if 
there  were  more  than  three  libraries,  because  one  library  would  have  to  incorporate  components 
firom  many  libraries  into  its  library  model.  Thus,  any  changes  to  the  interoperability  technical 
concept  should  be  incorporated  into  any  interoperability  agreement. 

Since  the  components  from  the  "cooperating"  libraries  are  integrated  into  the  local  library’s 
model/schema,  the  user  does  not  get  the  benefit  of  the  model/schema  of  the  other  libraries. 
Also,  users  do  not  know  what  components  they  do  not  have  access  to,  that  may  be  beneficial 
to  them.  Under  the  ciurent  structure,  a  user  only  is  allowed  to  access  the  components  that  the 
other  two  libraries  submit  to  their  indices.  Currently,  many  users  have  accoimts  with  more  than 
one  library.  In  doing  so  they  can  view  (take  advantage  of)  the  other  libraries’  mechanism/index 
schema/library  model,  as  well  as  view  those  components  that  are  not  made  available  via  the 
index.  This  may  cause  a  user  to  obtain  accounts  on  all  three  libraries,  and  then  to  determine  the 
best  components  (and  the  best  library)  that  meets  their  needs. 

The  current  system  works  well  with  non-COTS  products  and  public  domain  software,  since  these 
can  be  transferred  between  the  libraries  with  no  approval.  The  current  Tri-lateral  interoperability 
index  structure  includes  a  variable  for  distribution  limitations/ownership.  However,  there  are 
no  detailed  implementation  plans  for  transferring  commercial  components. 

The  tri-lateral  MOU  will  contain  some  roles  and  responsibilities  regarding  transferring  funds 
from  one  library  to  another  for  access,  taxes,  and  royalty  fees.  However,  none  of  the  libraries 
have  fee-f(»r-service  in  place  and  only  one  has  a  detailed  plan.  It  is  recommended  that  the 
libraries  com'dinate  their  plans  for  fee-fOT-service  implementation  to  ensure  compatibility. 

Currently,  two  of  the  three  interoperating  libraries  allow  only  Government  agencies  and  their 
contractors  to  become  users.  They  do  not  allow  prospective  contractors,  commercial  entities, 
nOT  representatives  from  academia.  This  does  make  sense  since  the  minimum  user  clearance 
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was  determined  to  be  "Sensitive  Unclassified".  If  the  components  in  the  libraries  that  have 
produced  this  security  level,  turn  out  to  be  a  small  percentage  of  the  libraries  total  collection, 
then  perhaps  it  would  be  best  not  to  include  those  components  (ex'  have  restricted  access  to 
them)  and  to  allow  prospective  contractors,  commercial  organizations  and  representatives  from 
academia  to  become  users.  Again,  the  three  libraries  should  coordinate  any  plans  or  policies  f<x 
changing  restrictions  of  user  types  so  that  they  are  properly  incoiporated  into  the  interoperating 
policies  and  procedures. 

When  interoperating  with  2  other  libraries,  each  library  must  incorporate  components  from  the 
other  2  libraries  into  its  model/schema.  Also,  each  library  must  keep  track  of  component  status 
and  component  ownership  of  these  additional  components.  With  three  libraries,  this  is  a  viable 
task,  however,  it  becomes  more  difficult  when  there  are  many  more  than  three  libraries  and  when 
not  all  of  these  libraries  are  Government  owned.  In  the  tri-lateral  MOU,  each  library  agrees  not 
to  include  in  their  permanent  collection  any  compoiwnt  from  any  other  library.  Thus,  the  current 
procedure  for  component  control  appears  to  be  a  "first  come,  first  serve"  rule.  Currently  with 
reuse  library  interoperability,  all  the  libraries  are  Government  owned,  so  that  the  Govermnent 
could  have  control  over  which  library  includes  which  components  in  its  collection.  In  the  future, 
when  additional  libraries  are  brought  into  the  interoperability  mechanism,  it  should  be  determined 
beftMV  hand  which  library  will  maintain  control  of  a  component.  Perhaps  the  components  could 
be  delineated  by  domain. 
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APPENDIX  B  -  Acronyms 


AFS 

Andrew  File  System 

ASSET 

Asset  Source  fra*  Software  Engineering  Technology 

CARDS 

Central  Archive  for  Reusable  Defense  Software 

CLARF 

CARDS  Library  Account  Registration  Form 

COTS 

Commercial-Off-The-Shelf 

DFARS 

Defense  Federal  Acquisition  Regulation  Supplement 

DSRS 

Defense  Software  Repository  System 

FAR 

Federal  Acquisition  Regulation 

FOIA 

Freedom  of  Information  Act 

GOCO 

Govmunent  Owned-Contractor  Operated 

GOTS 

Govemment-Off-The-Shelf 

GPLR 

Government  Purpose  License  Rights 

MOA 

Memorandum  of  Agreement 

MOU 

Memorandum  of  Understanding 

SBIR 

Small  Business  Innovative  Research 
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Component 


Contracting  Agency 
Contract  Liability 


Contractor 

Negligence 


Ownership 


Patent 


Prospective  Contractor 
Statutory  Liability 

Strict  Liability 

Subscriber 


APPENDIX  C  •  Glossary 

Any  reusable  item  (e.g.,  requirements,  specifications, 
designs,  object  code,  source  code  or  system/software 
documentation)  pertaining  to  computer  software  or  its 
dociunentation. 

The  federal  agency  contracting  for  the  software. 

A  contract  basis  of  liability  is  derived  from  agreements 
which  might  be  oral  or  written  (preferably  written). 
Contract  liability  results  when  one  party  or  the  other 
breaches  a  term  (provision)  of  the  contract  [CARDS93a]. 

A  person  or  organization  performing  a  current  contract. 

Conduct  that  falls  below  the  standard  established  by  law 
to  protect  against  unreasonable  risk  of  harm;  harmful 
defects  that  could  have  been  detected  and  corrected 
through  reasonable  quality  control  practices  [SEI] 

Holding  title  to  tangible  property  (e.g.,  owner  of  an  au¬ 
tomobile  under  state  issued  certificate  of  title)  [EDWK- 
SHP]. 

Patents  protect  ideas  and  give  the  inventor  the  exclusive 
right  to  prevent  others  from  making,  using  or  selling  the 
invention  for  seventeen  years  after  the  patent  is  issued 
[EDWKSHP].  (Note:  patent  protection  for  software  is 
not  only  new,  but  is  controversial). 

A  person  ex  organization  engaged  in  preparing  responses 
to  solicitations. 

A  statut(»y  basis  for  liability  requires  neither  9  contract 
nor  the  existence  of  any  duty  under  tort  law,  but  is 
covered  under  statute  or  laws  (e.g.,  copyright  law) 
[CARDS93a]. 

A  part  of  tort  law  that  covers  damage  caused  by  (x 
threatened  by  unreasonably  dangerous  products;  the 
product  contains  one  or  more  unreasonably  dangerous 
defects  [S^. 

A  person  or  organization  who  accesses  the  library  for 
purpose  of  assessing  utility  of  components  for  possible 
reuse  in  a  Government  purpose  undertaking 
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Supplier 


Tat  Li;-'c)ility 


Trade  Secret 


Warranty 


A  person  or  organization  who  submits  components  (and 
updates  if  t^plicable)  fa  inclusion  into  the  library’s 
collection. 

A  duty  to  provide  a  certain  "standard  of  care"  which  is 
expected  from  anotha  party.  This  is  derived  from  the 
common  law  of  tort  [CARDS93a]. 

Any  formula,  process,  design  a  intellectual  property 
interest  which  is  protected  by  secrecy  [EDWKSHP]. 

Assure  customers  that  the  products  will  perform 
stated;  can  limit  the  supplia’s  liability  in  the  event 
nonperformance  [SEI] 
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